View 28960-SWG-001-A_8599688.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

bt8960 software user s guide 100251b september 2000
100251b conexant preliminary information/conexant proprietary and confidential ? 1996, 2000, conexant systems, inc. all rights reserved. information in this document is provided in connection with conexant systems, inc. (?conexant?) products. these materials are provided by conexant as a service to its customers and may be used for informational purposes only. conexant assumes no responsibility for errors or omissions in these materials. conexant may make changes to specifications and product descriptions at any time, without notice. conexant makes no commitment to update the information and shall have no responsibility whatsoever fo r conflicts or incompatibilities arising from future changes to its specifications and product descriptions. no license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document. exce pt as provided in conexant?s terms and conditions of sale for such products, conexant assumes no liability whatsoever. these materials are provided ?as is? without warranty of any kind, either express or implied, relating to sale and/or use of conexant products including liability or warranties relating to fitness for a particular purpose, consequential or incidental damages, merchantability, or infringement of any patent, copyright or other intellectual property right. conexant further does not warrant the accuracy or completeness of the information, text, graphics or other items contained within these materials. conexant shall not be liable for any special, indirect, incidental, or consequential damages, including without limitation, lost revenues or lost profits, which may result from the use of these materials. conexant products are not intended for use in medical, lifesaving or life sustaining applications. conexant customers using or selling conexant products for use in such applications do so at their own risk and agree to fully indemnify conexant for any damages resulting from such improper use or sale. the following are trademarks of conexant systems, inc.: conexant?, the conexant c symbol, and ?what?s next in communications technologies??. product names or services listed in this publication are for identification purposes only, and may be trademark s of third parties. third-party brands and names are the property of their respective owners. for additional disclaimer information, please consult conexant?s legal information posted at www.conexant.com , which is incorporated by reference. reader response: conexant strives to produce quality documentation and welcomes your feedback. please send comments and suggestions to tech.pubs@conexant.com . for technical questions, contact your local conexant sales office or field applications engineer.
100251b conexant iii preliminary information/conexant proprietary and confidential table of contents list of figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix list of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi 1.0 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 1.1 how to use this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 1.2 contents of this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 2.0 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 2.1 software structure and operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 2.2 portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 2.3 integration with application-specific software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 2.4 software interfacing with the bt8960 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 3.0 software application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3.1 system configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 3.2 setting bit-pump parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 3.3 activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 3.4 test modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 3.5 internal ber meter operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 3.5.1 calculating avg ber and elapsed time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 4.0 software structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 4.1 software block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 4.2 user-called routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 4.3 memory requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 5.0 compiling the source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 5.1 directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 5.2 file names and dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 5.2.1 compilation directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 5.2.2 code modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
bt8960 software user?s guide iv conexant 100251b preliminary information/conexant proprietary and confidential 6.0 user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 6.1 command structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 6.2 serial communication interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5 6.2.1 communication protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5 6.2.2 message transfer protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5 6.2.3 message structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6 6.2.4 checksum function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7 6.3 code level interface (api) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8 6.3.1 _btcontrol() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8 6.3.2 _btstatus() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9 6.3.3 user defined api commands - channel unit & framer . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9 6.4 opcodes and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11 appendix a command set reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-1 a.1 control commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-1 a.1.1 terminal type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-1 a.1.2 analog agc configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-2 a.1.3 start-up sequence source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-3 a.1.4 transmit scrambler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-4 a.1.5 receive descrambler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-5 a.1.6 data transfer format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-6 a.1.7 other side bt8960 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-7 a.1.8 lost time period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-7 a.1.9 bit-pump on/off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-8 a.1.10 transmit external data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-8 a.1.11 activate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-9 a.1.12 deactivate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-9 a.1.13 test mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-10 a.1.14 symbol rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-12 a.1.15 reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-12 a.1.16 operate non-linear ec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-13 a.1.17 write transmitter gain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-13 a.1.18 tip/ring reversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-14 a.1.19 ber meter start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-14 a.1.20 ber meter stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-15
bt8960 software user ? s guide 100251b conexant v preliminary information/conexant proprietary and confidential a.2 status request commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-16 a.2.1 input signal level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-16 a.2.2 input dc offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-16 a.2.3 far-end signal attenuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-17 a.2.4 noise margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-18 a.2.5 timing recovery control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-18 a.2.6 bit-pump status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-19 a.2.7 read linear echo canceler coefficient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-20 a.2.8 read non-linear echo canceler coefficient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-21 a.2.9 read eq coefficient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-21 a.2.10 read dfe coefficient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-22 a.2.11 software/chip version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-23 a.2.12 bit-pump present . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-24 a.2.13 self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-24 a.2.14 read bt8960 register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-25 a.2.15 bit-pump configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-25 a.2.16 stage number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-26 a.2.17 aagc value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-27 a.2.18 read tx gain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-27 a.2.19 ber meter status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-28 a.3 special messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-29 a.3.1 acknowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-29 appendix b calibrating noise margin table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b-1 b.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b-1 b.1.1 setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b-1 b.1.2 noise margin table calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b-1 appendix c erle diagnostic code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-1 c.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-1 c.2 what is erle? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-1 c.3 erle files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-2 c.3.1 _erle() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-2 c.3.2 _measureaagc() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-2 c.4 invoking the tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-3 c.4.1 background test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-3 c.4.2 erle and analog erle test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-3 c.4.3 aagc check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-3 c.5 compiling the erle code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-3 c.5.1 tdebug compiler flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c-3
bt8960 software user ? s guide vi conexant 100251b preliminary information/conexant proprietary and confidential appendix d release notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-1 d.1 memory requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-1 d.1.1 bug fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-2 d.1.2 support new bt8960 rev c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-2 d.1.3 improved performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-3 d.1.4 new / modified features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-3 d.1.5 new api commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-4 d.1.6 internal ber meter operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-6 d.1.7 ber meter bit-pump code implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-8 d.2 bt8960 bit-pump version 1.1, release notes?september 2, 1996 . . . . . . . . . . . . . . . . . . . . . d-9 d.2.1 pll modes clk_freq bits were incorrect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-9 d.2.2 added erle support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-9 d.2.3 bt8960evm single board support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-9 appendix e version 1.1 release notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e-1 e.1 pll modes clk_freq bits were incorrect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e-1 e.2 added erle support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e-2 e.3 bt8960evm single board support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e-2 e.3.1 user.c - different bit-pump address mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e-2 e.3.2 script.bld - xdata mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e-2 e.3.3 application code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e-2
bt8960 software user ? s guide 100251b conexant vii preliminary information/conexant proprietary and confidential
bt8960 software user ? s guide viii conexant 100251b preliminary information/conexant proprietary and confidential
bt8960 list of figures software user ? s guide 100251b conexant ix preliminary information/conexant proprietary and confidential list of figures figure 3-1. example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 figure 4-1. bt8960 software modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 figure 5-1. user-modifiable code section format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5 figure 6-1. two microprocessors implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 1 figure 6-2. single microprocessor implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 -2 figure 6-3. command structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 figure 6-4. host processor to 8032 message structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6 figure 6-5. 8032 to host processor message structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7 figure d-1. example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-7
list of figures bt8960 software user ? s guide x conexant 100251b preliminary information/conexant proprietary and confidential
bt8960 list of tables software user ? s guide 100251b conexant xi preliminary information/conexant proprietary and confidential list of tables table 3-1. user configurable parameters and their default values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 table 3-2. start-up status parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 table 3-3. additional status parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 table 3-4. bt8960 test modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 table 3-5. analog loopback vs. version relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 6 table 4-1. bt8960 software routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 table 4-2. memory requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 table 5-1. source file names and dependencies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 table 6-1. destination field specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 table 6-2. destination field values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10 table 6-3. user interface command summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11 table a-1. bt8960 again settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-3 table a-2. exiting test modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-10 table a-3. status bits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-20 table a-4. low application setup byte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-26 table a-5. high application setup byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a-26 table d-1. ram and rom requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .d-1 table d-2. version relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . d-3
list of tables bt8960 software user ? s guide xii conexant 100251b preliminary information/conexant proprietary and confidential
100251b conexant 1-1 preliminary information/conexant proprietary and confidential 1 1.0 introduction the bt8960 single chip 2b1q transceiver (also referred to as bit-pump) chip is designed to be controlled by an external microprocessor. the microprocessor sets and controls all bt8960 internal operation modes during activation, monitors the bit-pump?s performance during normal operation, and implements steady-state activities such as micro-interruptions recovery. a single processor may control up to six bit-pump chips. the bt8960 software implements all the necessary bit-pump control and monitoring operations, including activation process, performance monitoring, and test modes. this software package is an integral part of the bt8960 bit-pump, and must be used without any significant changes in order to guarantee correct operation and optimal bit-pump performance. the software is supplied in both c source code format and intel 8032 object code format. the object code software may be used in a system employing intel?s 8032 controller to control the bt8960 chip, or in a specific hardware configuration which employs a second ?host? processor that runs the user code and communicates with the 8032 through the serial communication channel (similar to brooktree?s hdsl evm system). such a design will require no user code modifications. if a non-8032 processor is used, or if an 8032-based system implements different hardware design, the c source code version should be compiled together with necessary modifications for the target processor of choice. a major design goal for the bt8960 software is portability and ease of conversion for different hardware and compiler environments. however, this cannot completely eliminate the need to ?tune? the software for specific implementations because of the hardware-dependent nature of the code. this manual includes detailed instructions to allow for modification of this code. all application interactions with the bt8960 are done via a user interface protocol, which is implemented either at the code level (for applications integrating the software in a ?single processor? configuration) or by using a serial communication channel (for systems employing an 8032 controller and an additional host processor in a ?dual processor? configuration). the bt8960 software is conceptually broken up into two sections of code: application code and bit-pump code. the application code section is inevitably the responsibility of the end user. brooktree offers a complete evaluation system (evm) which implements an example of this application code. to obtain the evaluation system, contact your local sales representative.
1.0 introduction bt8960 software user ? s guide 1-2 conexant 100251b preliminary information/conexant proprietary and confidential the bt8960 bit-pump software handles the complete activation process without any need for application intervention. all bit-pumps may go through activation in parallel, with practically no degradation of activation time. the user interface allows access to all parameter status required to implement an hdsl system, including noise margin, pulse attenuation, loss of signal (los), etc. although no dsp tasks are performed by the control software, some sections of the code involve real-time operations, especially during activation. applications that integrate the bt8960 software should take this into account and follow the software integration instructions.
bt8960 1.0 introduction software user ? s guide 1.1 how to use this manual 100251b conexant 1-3 preliminary information/conexant proprietary and confidential 1.1 how to use this manual this manual contains all the necessary information required to successfully modify, compile, and use the bt8960 software. it is highly recommended that this manual is read prior to writing application code for the bt8960. the chapters ? software structure ? through ? software integration ? are particularly important for those using the source code version of the software to integrate the code with their own software. use the ? compiling the source code ? chapter when modifying and compiling the source code. refer to the ? software integration ? chapter when integrating the application software with the bt8960 code. the bt8960 is controlled using the software user interface. use the detailed information given in the ? user interface ? chapter when writing the bt8960 application software. appendix a serves as a reference to the control and status command set. the ? software application ? chapter contains information on how to use the bt8960 software and user interface command set in a transceiver application. it outlines the required initialization and parameter setting sequence, accompanied by examples of a typical application.
1.0 introduction bt8960 1.2 contents of this manual software user ? s guide 1-4 conexant 100251b preliminary information/conexant proprietary and confidential 1.2 contents of this manual chapter contents overview overview of the software design principles, portability considerations, hardware-related issues, application interface principles, and application code integration constraints. software structure description of the code structure, main routines, file names, and reserved names. software operation software operation principles, including the application interface and activation code sections. compiling the source code explains how to modify and compile the c source code to match the application hardware/software environment. software integration explains how to integrate the application software with the bt8960 software. user interface details of the user interface operation, command structure, and status responses. software application how to use the bt8960 software and user interface in an hdsl transceiver application. command set reference lists control and status request commands, including opcodes, parameter values, etc.
100251b conexant 2-1 preliminary information/conexant proprietary and confidential 2 2.0 overview 2.1 software structure and operation the bt8960 software is responsible for handling and monitoring the activation and normal operation activities of up to six bt8960 hdsl bit-pumps. the bt8960 software includes the following five major functional blocks: 1. application ? contains the application specific code to initialize the system and to control any system level tasks. 2. btmain ? activates the bit-pump control process for each of the bt8960 chips present in the system. it also calls routines that handle messages received on the serial communication channel. 3. bt8960 control ? the principal bit-pump control routine. the control routine goes through a series of states that implement the various activation and normal operation activities. every call to the control routine executes the operations relating to a specific state, and the state variable is advanced to the next state. the same routine is used for all active bit-pump chips, only the state variable being bit-pump specific. 4. user interface ? receives and executes user commands, and sending back status information. the interface is implemented either at the code level, called the application-program interface (api) (when an application is integrated with the bt8960 software) or via a serial communication protocol. in both control options, the interface is based on a set of commands issued and parameter status returned. 5. interrupt handler ? this routine is entered every time one of the bt8960 chips initiates an interrupt. most interrupts are handled by setting appropriate software flags.
2.0 overview bt8960 2.2 portability software user ? s guide 2-2 conexant 100251b preliminary information/conexant proprietary and confidential 2.2 portability the bt8960 software is designed with code portability as a major goal. this approach creates a c code that can be easily modified to match different hardware and software environments. the code itself has hardware-related parameters which must be defined. for example, the absolute address space allocated to each of the bt8960 chips depends on the specific hardware design and address decoding details. another example of a hardware/software-dependent code section is the definition of the bt8960 interrupt handling routine. the routine itself is part of the supplied software (and should not be modified) but the routine header definition and notation is both processor and compiler dependent. these examples demonstrate the kind of modifications required in the source code in order to successfully compile and run the bt8960 software. the ? compiling the source code ? chapter describes all of the required modifications. in addition, these modifications are clearly marked and commented in the source files. 2.3 integration with application-specific software the bt8960 software controls and sequences all the activation operations which include real time operations. in a system where the bt8960 software shares processing resources with the user ? s application software, care must be taken to not impair bit-pump performance. guidelines to handle real-time operations within applications are described and explained in detail in the ? software integration ? chapter of this manual.
bt8960 2.0 overview software user ? s guide 2.4 software interfacing with the bt8960 100251b conexant 2-3 preliminary information/conexant proprietary and confidential 2.4 software interfacing with the bt8960 since all bit-pump operations (activation, performance monitoring, etc.) are handled by the bt8960 software, all user interaction with the bit-pumps is done through the bt8960 software and not by directly accessing the bt8960 chip. in some cases, performing a read/write operation can impair the proper operation of the control software. the bt8960 software contains a user interface (ui) module that allows full control over the operation of the bit-pumps and performance monitoring. the ui is based on a set of issued commands, and the bt8960 software responds by performing the required action or supplying the required status. when used in the single processor configuration, it is highly recommended that the api and ui be used to ensure easy integration with code updates. there are two configurations for transferring commands and parameter status between an application and the bt8960 software. in a single processor design, the interface is done using two api (application-program interface) routines that are part of the bt8960 software. the application issues commands and receives status by calling these routines. in a dual processor design, the bt8960 bit-pumps are controlled by an 8032 processor and the application interfaces to the bit-pumps through the serial communication (uart) channel. in this configuration, the commands and status are sent as messages over the serial channel. both configurations use exactly the same set of commands. this command set is designed for maximum flexibility in operating the bit-pumps, and supplies all the necessary performance and status monitoring information. each bit-pump can be controlled and monitored individually via the ui. the ? user interface ? chapter describes the structure of the commands and the communication protocol for both ui configurations in detail. appendix a is a reference guide to the set of commands and status bits, with details on command use, syntax, and operation.
2.0 overview bt8960 2.4 software interfacing with the bt8960 software user ? s guide 2-4 conexant 100251b preliminary information/conexant proprietary and confidential
100251b conexant 3-1 preliminary information/conexant proprietary and confidential 3 3.0 software application interaction with the bt8960 bit-pumps is done by using the set of control and status request commands. this chapter addresses the issue of applying these commands in a complete hdsl transceiver system. 3.1 system configuration before any other command or status request may be issued to a bit-pump, the system configuration needs to be defined, using the bit-pump on/off command. this informs the bt8960 software which bit-pump is on. following power up, all bit-pumps are declared to be off. all commands (other than system configuration) sent to a bit-pump that is turned off are ignored by the bt8960 software. turning on a bit-pump means that the corresponding bt8960 is installed in the system and is intended to be used. not all bt8960s that are installed in the system must be turned on. a bit-pump may be turned on or off at any time, and any combination of bit-pumps turned on or off is allowed. turning a bit-pump on (even if it is turned on already) resets the corresponding bt8960, and all configured parameters must be reprogrammed.
3.0 software application bt8960 3.2 setting bit-pump parameters software user ? s guide 3-2 conexant 100251b preliminary information/conexant proprietary and confidential 3.2 setting bit-pump parameters for proper operation of the bit-pumps, all configuration and operation parameters must be set to their correct values (depending on the specific application) prior to activating the bit-pumps. these parameters include design-specific information (such as analog agc configuration, data transfer format, activation sequence source, etc.) and application specific parameters (such as symbol rate, terminal type, etc.). all parameters and configuration options have default values (see appendix a). only those parameters that have values different than the default need to be programmed. table 3-1 lists all the user-programmable parameters together with their default values. see the ? user interface ? chapter and appendix a for details regarding the use and syntax of the specific commands used to set these parameters. note: the _sym_rate command must be immediately issued after the _system_config on command. table 3-1. user configurable parameters and their default values parameter default bit-pump on/off off terminal type htu-c other side bt8960 non-bt8960 analog agc configuration no agc symbol rate 144 k symbol/sec lost time period 1sec data transfer format serial start-up sequence source external transmitter scrambler on / bypass bypass receiver descrambler on / bypass bypass operate non linear ec off transmitter gain calibration value
bt8960 3.0 software application software user ? s guide 3.3 activation 100251b conexant 3-3 preliminary information/conexant proprietary and confidential 3.3 activation upon power-up, the bit-pumps move to an idle state where no activities take place. no signal is transmitted and the bit-pumps will not respond in any way to input signal detection. to initiate a activation procedure, an activate command should be issued at the htu-c and htu-r terminals. this results in the transmission of a 2-level activation sequence, and begins the sequence of activation activities on the htu-c. under normal operating conditions, the htu-r should detect the incoming signal and respond according to the standard activation protocol. the htu-r bit-pump will respond in this way only if an activate command was issued on the htu-r terminal. note that the activate command on the htu-r does not initiate a response, but enables such a response once a signal is detected. the order in which the activate commands are issued at the htu-c and htu-r terminals is of no importance, but the complete activation procedure will take place only when both terminals are activated. when the htu-c is activated first, it starts a 2-level transmission, but will get no response from the htu-r until the htu-r has been activated. it will therefore wait until an htu-r signal is detected, and then proceed with the activation. when the htu-r is activated first, it will wait for the detection of an htu-c signal. once the htu-c has been activated it starts transmitting, and the htu-r, upon detecting this transmission, will proceed with the activation. once both terminals are activated, the complete sequence of activation activities is carried out on both terminals according to the standard protocol. no user intervention is required during this process.
3.0 software application bt8960 3.3 activation software user ? s guide 3-4 conexant 100251b preliminary information/conexant proprietary and confidential it is the responsibility of the application software to monitor the appropriate status responses, in addition to channel unit frame sync status, during activation, and decide whether or not the activation has been successfully completed. the important status parameters for activation monitoring include noise margin, loss of signal (los, lost), transmit 4-level indicator, and activation timers expiration. table 3-2 describes these together with the specific status request commands that are used to access each status parameter. table 3-3 shows additional bit-pump responses that do not relate directly to the activation procedure. further information may be found in the ? user interface ? chapter and in appendix a. table 3-2. start-up status parameters indication description command name noise margin an estimate of the noise margin (in db), indicating the tolerable increase in noise level while still maintaining a ber<1e?7. noise margin noise margin ok 1 indicates noise margin higher than ?5 db. bit-pump status los 0 indicates the presence of an incoming signal, 1 indicates no input signal present. status is based on average far-end signal power measurement. this status is valid at all times. bit-pump status lost 1 indicates the presence of a los condition for more than the lost time period (programmable). the lost response is valid only after a deactivate command is issued. bit-pump status activation timer 1 indicates expiration of the activation interval. bit-pump status transmit 4-level 1 indicates the bitpump is transmitting a 4-level signal. bit-pump status normal operation 1 indicates the bitpump has completed the stages of the activation process. bit-pump status table 3-3. additional status parameters indication description command name total input signal level average absolute level of signal at the input to the a/d. this signal is composed of both the far-end and echo signals. input signal level input dc offset average dc offset at the input to the a/d. a high value may cause performance degradation. input dc offset cable attenuation total signal attenuation (in db). far-end signal attenuation frequency deviation value of the (digital) vcxo control signal. vcxo control voltage
bt8960 3.0 software application software user ? s guide 3.4 test modes 100251b conexant 3-5 preliminary information/conexant proprietary and confidential 3.4 test modes the bt8960 may be operated in special test modes, used during development and field operation, for maintenance and fault identification. all test modes are activated using the test mode command, with the command parameter value selecting the specific mode. to exit a test mode, issue the test mode command with the _exit_test_mode (0x00 value) parameter. the action taken when exiting a test mode condition depends on the specific test mode selected. activating most test modes while the bit-pump is synchronized will cause the bit-pump to lose sync. exiting the test mode and going back to normal data transfer condition will require full restart. in these cases, the bit-pump goes to the idle state when exiting the test mode. other test modes do not create a sync loss condition, and normal operation may continue when exiting the test condition. when exiting one of these test modes, the bit-pump goes back to the state that was active when the test mode command was issued. table 3-4 describes the available test modes, and shows for each mode the ability to go back to normal operation. further information may be found in the user interface section and in appendix a. table 3-4. bt8960 test modes (1 of 2) test mode description sync loss external analog loopback transmits the externally supplied tx symbols, use the echo signal as a ? received ? signal, and detect the symbols using the standard equalizer. digital ? near ? loopback tx symbols supplied to the bit-pump (by the framer) are looped back as the rx symbols going from the bit-pump to the framer. useful for testing the framer and the framer-bit-pump connection. digital ? far ? loopback detected (rx) symbols are transmitted back on the loop. useful for testing full 2-way transmission over a loop. note: the operation of a digital ? far ? loopback requires activating the bt8960 internal tx scrambler and rx descrambler. transmit isolated +3 pulse transmits (repeatedly) an isolated +3 level pulse. useful for testing the transmitted pulse shape. transmit isolated +1 pulse transmits (repeatedly) an isolated +1 level pulse. transmit isolated ? 1 pulse transmits (repeatedly) an isolated ? 1 level pulse. transmit isolated ? 3 pulse transmits (repeatedly) an isolated ? 3 level pulse. continuous 4-level transmission continuous transmission of a 4-level scrambled 1's sequence (internally generated). useful for measuring transmitted power and spectral shape. continuous 2-level transmission continuous transmission of a 2-level scrambled 1 ? s sequence (internally generated). set minimum vcxo frequency sets vcxo control word to its minimum value. set nominal vcxo frequency sets vcxo control word to its nominal value. useful for measuring vcxo center frequency.
3.0 software application bt8960 3.4 test modes software user ? s guide 3-6 conexant 100251b preliminary information/conexant proprietary and confidential table 3-5 shows the relationship between the chip revision, software version, and analog loopbacks supported. set maximum vcxo frequency sets vcxo control word to its maximum value. internal analog loopback transmits the externally supplied tx symbols out the txp and txn pins and detects the symbols on the hybrid inputs (rxbp, rxbn), the receive inputs (rxp and rxn) are bypassed. isolated analog loopback the externally supplied tx symbols are internally looped back in the bt8960. the transmitter (txp and txn) is turned off (silent). table 3-4. bt8960 test modes (2 of 2) test mode description sync loss table 3-5. analog loopback vs. version relationships version external internal isolated v 1.x none none none v 2.0+ rev. b and c rev c only rev c only
bt8960 3.0 software application software user ? s guide 3.5 internal ber meter operation 100251b conexant 3-7 preliminary information/conexant proprietary and confidential 3.5 internal ber meter operation this section describes how to use the bt8960 ? s internal ber meter. the ber meter code is only accessible when the ber_meter compiler flag is declared. the ber meter can be used to verify the integrity of the line, and as a diagnostic tool during production/field testing or hardware/software development. the ber meter uses its internal scrambled ones generator and de-scrambler to detect bit-errors. for the ber meter to function properly, both the htu-c and htu-r must issue the _ber_meter_start api command. since the ber meter uses its own internal scrambled ones generator, it cannot be used when transporting real payload data. the ber meter is only operational after the bit-pump has successfully completed startup. all access to the ber meter is done through the api, see appendix a. the interrupt handler reads the bit error rate meter register (address 0x4c, 0x4d) and updates the number of bit-errors and number of meter intervals counter after every meter interval. this causes the interrupt handler to be slightly longer, ~55us per bit-pump on an 11.0592mhz intel 8032. 3.5.1 calculating avg ber and elapsed time the following formulas are used to calculate the avg ber and elapsed time. avgber ofbiterror s ofmeterint ervals meterinter vallength = # #* *2 elapsedtim e ofmeterint ervals meterinter vallength datarate = #* *2 variable how derived # of bit-errors read the # of bit-errors low & high byte api commands and build a 16-bit unsigned integer. # of meter intervals read the # of meter intervals low & high byte api commands and build a 16-bit unsigned integer. meter interval length read the bt8960 meter interval register (address 0x18, 0x19) and build a 16-bit unsigned integer. during normal operation, these registers should always read 0x8000 (32768). data rate data rate of the system, i.e. 288000 or 416000. 2the ? * 2 ? is necessary because there are 2 bits per symbol and the meter interval length is based on the number of symbols. note(s): 16-bit value = (high byte << 8) + (low byte)
3.0 software application bt8960 3.5 internal ber meter operation software user ? s guide 3-8 conexant 100251b preliminary information/conexant proprietary and confidential figure 3-1. example /* * assuming 288kbps data rate, normal operation, and ber meter active * also assumes using compiler/linker that supports floating point. */ void get_ber_meter_status (unsigned char no) { unsigned char temp, temp1; unsigned int errors, intervals; float avg_ber, elapsed_time; _btstatus(no, _ber_meter_status, _ber_bit_errors_low, &temp); _btstatus(no, _ber_meter_status, _ber_bit_errors_high, &temp1); errors = (unsigned)byte2word(temp1, temp); _btstatus(no, _ber_meter_status, _ber_meter_intervals_low, &temp); _btstatus(no, _ber_meter_status, _ber_meter_intervals_high, &temp1) intervals = (unsigned)byte2word(temp1, temp); avg_ber = (errors) / (intervals * 0x8000 * 2) /* equations don?t show necessary type casting */ elapsed_time = (intervals * 0x8000 * 2) / (288000) #if tdebug printf("# bit errors = %u\n", errors); printf("# meter intervals = %u\n", intervals); printf("avg ber = %.2e\n", avg_ber); printf("elapsed time = %.1f seconds\n", elapsed_time); #endif return; }
100251b conexant 4-1 preliminary information/conexant proprietary and confidential 4 4.0 software structure this chapter describes the structure of the bt8960 control software. the information is useful for understanding the bt8960 operation and the proper integration of bt8960 code with the application software. 4.1 software block diagram this section describes the major bt8960 software logical blocks and briefly outlines their function. figure 4-1 shows the major software modules and their relation with application specific software. figure 4-1. bt8960 software modules user set par ameters api indications htu-r activation se rial comm. btmain htu-c activation utility routines test modes bt8960 control interrupt handler user interface application-specific software 100251_001
4.0 software structure bt8960 4.1 software block diagram software user ? s guide 4-2 conexant 100251b preliminary information/conexant proprietary and confidential the application block contains the application ? s high level system tasks, i.e. activation state diagram, diagnostics, controlling other devices, etc. the _btmain() module is called by the application ? s main program, and it is important to ensure a periodic execution of this module within specified real-time constraints (see the ? software integration ? chapter for details). the _btmain() module is responsible for executing all the specific bt8960 tasks, including the bit-pump control operations, and the received/transmitted message handling. this is the highest level block in the bt8960 software hierarchy, and should be executed repeatedly and indefinitely to ensure proper operation of the bit-pumps. the bt8960 control block contains the bit-pump activation control routines (for the central office and remote terminals) and special test mode routines. the activation control routine is executed periodically for every active bt8960 chip. it goes through the complete activation procedure and handles normal operation monitoring activities. the test modes module is responsible for operating the bit-pump in a specified test mode, such as loopback, isolated pulse transmission, etc. the user interface block implements all the tasks related to communication with an application. this communication is either done through a serial communication protocol or by using code level api routines. the ui block interprets received commands, performs the required operation, and sends back status reports. the interrupt handler block responds to bt8960 interrupts, sets the software interrupt flags, and in special cases, performs bit-pump operations that cannot be delayed.
bt8960 4.0 software structure software user ? s guide 4.2 user-called routines 100251b conexant 4-3 preliminary information/conexant proprietary and confidential 4.2 user-called routines the routines found in table 4-1 must be called or accessed by the application software. further details regarding these specific routines are given in the ? user interface ? and the ? software application ? chapters and appendix a. further information and documentation may be found in the source files. table 4-1. bt8960 software routines routine / macro file name description _btswpowerup() btmain.c bt8960 software initialization. must be executed prior to any other bt8960 related operation. _maskbthomerint() btmain.c masks all bt8960 interrupts for all present bt8960 chips. _init8051() init51.c used only in 8032 environment. initializes 8032-specific parameters. _initvirtualtimers() intbug.c used only with the int_bug compiler flag. initializes virtual timers. _btcontrol() api.c api routine. called by the application to issue a control command. _btstatus() api.c api routine. called by the application to issue a status request command and to get the requested status. _btmain() btmain.c main bt8960 control routine. calls all bt8960 tasks. should be executed repeatedly and indefinitely.
4.0 software structure bt8960 4.3 memory requirements software user ? s guide 4-4 conexant 100251b preliminary information/conexant proprietary and confidential 4.3 memory requirements the code rom requirements depend on the compiler, processor in use, and compiler flags. the ram and rom requirements for four common build options with their associated compiler flags are shown in table 4-2 . 4.3.0.1 bt8960cr w/o ber_meter c51,add_delay,pdata_mode,ser_com,htuc,htur,single_loop,chan_unit 4.3.0.2 bt8960cr w/ ber_meter c51,add_delay,pdata_mode,ser_com,htuc,htur,single_loop,ber_meter, chan_unit 4.3.0.3 bt8960c w/ ber_meter c51,add_delay,pdata_mode,ser_com,htuc,single_loop,ber_meter, chan_unit 4.3.0.4 bt8960r w/ ber_meter c51,add_delay,pdata_mode,ser_com,htur,single_loop,ber_meter,chan_ unit the ram requirements do not include the stack size, an additional 24 bytes is required for the run-time stack. these requirements include the activation state diagram application example code. table 4-2. memory requirements build option ram rom bt8960cr w/o ber_meter 111 24.0 k bt8960cr w/ ber_meter 117 24.4 k bt8960c w/ ber_meter 117 20.0 k bt8960r w/ ber_meter 117 20.6 k
100251b conexant 5-1 preliminary information/conexant proprietary and confidential 5 5.0 compiling the source code this chapter contains detailed information on how to successfully modify and compile the source code to match the specific application environment. the code modifications are required in order to match the bt8960 code to the processor/compiler environment and to the details of the system hardware implementation. in addition to the source code modifications, compilation directives must be correctly declared at compile time. to get a fully working executable code, perform the following steps: 1. determine the correct compiler directives definitions suitable for the environment (see the compilation directives section). 2. modify or write all the application modifiable sections by following the instructions in this chapter. 3. compile and link all the source files. use the file list and dependency information given in the file names and dependencies section. note: if the c51 flag is declared (indicating an 8032 family processor and keil & franklin c51 compiler), modify or write only specific application sections (see the code modifications section). 5.1 directory structure the directory structure is partitioned into two directories. the main (application specific) directory as the root and the bit-pump code as a sub-directory labeled bitpump. the application examples, hex files, build script files, etc. are found in the main directory. all of the bit-pump source code and header files are found in the bitpump subdirectory. however, the final implementation of the directory and file structure is up to the user.
5.0 compiling the source code bt8960 5.2 file names and dependencies software user ? s guide 5-2 conexant 100251b preliminary information/conexant proprietary and confidential 5.2 file names and dependencies table 5-1 lists all the files that should be compiled and linked in order to get a complete, executable bt8960 control code. the table also shows the dependency between the various files. table 5-1. source file names and dependencies file to be compiled file depends on... api.c bthomer.h bitpump.c bthomer.h btint.c bthomer.h btmain.c bthomer.h init51.c bthomer.h intbug.c bthomer.h mail.c bthomer.h main.c bthomer.h serint.c bthomer.h suc.c bthomer.h sur.c bthomer.h suutil.c bthomer.h testmode.c bthomer.h user.c bthomer.h util.c bthomer.h erle.c bthomer.h other files file depends on... bthomer.h btmain.h, mail.h, init51.h, intbug.h, serint.h, bitpump.h, suc.h, sur.h, suutil.h, util.h, api.h, testmode.h, user.h, ptrdef.h, reg51.h, erle.h
bt8960 5.0 compiling the source code software user ? s guide 5.2 file names and dependencies 100251b conexant 5-3 preliminary information/conexant proprietary and confidential 5.2.1 compilation directives the compilation directives select different code sections for compilation, and are used in code sections that are either hardware dependent or compiler dependent. accurate declaration of these directives is necessary to generate a correctly working executable code. note: it is extremely important that after declaring these directives, all of the source modules be recompiled to ensure the changes propagate throughout the entire executable. failure to do so will result in unpredictable behavior. 5.2.1.1 #single_loop; #two_loops; #three_loops; #four_loops; #six_loops these compiler flags allow the developer to specify the maximum number of loops supported in their system. one and only one of these flags must be defined at a time. the bit-pumps are allocated in a sequential order starting with _bit_pump0 (1st bit-pump) and ending with _bit_pump5 (6th bit-pump) only the bit-pumps that are supported by the specified compiler flag may be accessed during run-time, otherwise unpredictable behavior will result. for example, if three_loops is defined, then only _bit_pump0, _bit_pump1, and _bit_pump2 may be addressed. each subsequent loop adds ~8 bytes of rom space and ~4 bytes of ram. 5.2.1.2 #c51 the c51 flag should be declared when the bt8960 software is executed on an intel 8032 family microprocessor and the keil/franklin c compiler is used to compile the source code. if another intel 8032 family compiler is used, the c51 compiler flag may be defined. the user must be aware there may be compatibility issues between the compilers. if any non intel 8032 family microprocessor and c compiler are used, do not declare the c51 flag. 5.2.1.3 #pdata_mode, #xdata_mode the pdata_mode and xdata_mode flags can only be declared together with the c51 flag. the pdata_mode and xdata_mode flags set the addressing mode used to access the bt8960 chips. one and only one of these flags must be declared in a c51 system. the pdata_mode flag selects page mode addressing which results in reduced rom requirements for code space and faster execution. the xdata_mode flag selects external non-paged addressing. this results in greater code size and rom requirements, and somewhat slower execution of the control code. for pdata_mode, in each of the bit-pump functions, the p2 port is set to address the specified bit-pump. in addition, the bit-pump interrupt saves the p2 port value before addressing the bit-pumps, then restores the previous p2 port value on exit of the interrupt function. special care must be taken so that the p2 port value does not get erroneously modified by any other interrupt handler or another section of code. note: if the franklin & keil compiler ? s large memory model is defined, the xdata_mode compiler flag should be set since all variables are declared in xdata space.
5.0 compiling the source code bt8960 5.2 file names and dependencies software user ? s guide 5-4 conexant 100251b preliminary information/conexant proprietary and confidential 5.2.1.4 #ser_com the ser_com flag enables the serial communication protocol of the user interface. it is used in the dual processor mode of operation. it should be declared in an 8032-based system that employs the serial communication configuration for controlling the bt8960. the ser_com flag may be declared only if the c51 flag is declared. 5.2.1.5 #add_delay defining the add_delay flag causes the addition of a 2-symbol delay before accessing specific addresses in the bt8960. this additional delay is required when a read/write operation to the bt8960 is performed in less than a symbol time period. the delay is added only for very specific bt8960 addresses where the read/write operations are limited to one access per symbol. the add_delay flag should be declared only when the external read/write cycle time of the microprocessor is faster than the symbol rate. 5.2.1.6 #htur; #htuc the htur and htuc flags control whether htu-r or htu-c code is included in the executable. for applications where there is no distinction between htu-r and htu-c, except at the time of installation, having a single piece of code that serves as htu-r and htu-c is useful. for these applications both htur and htuc should be declared. if code space is a constraint, the htu-r and htu-c code can be customized for each terminal type. since the control process for each terminal type is in separate code, and represents a substantial portion of the code, it is possible to save rom space by only declaring htur for the htu-r terminal code and htuc for the htu-c terminal code. in this case the _terminal_type command would be fixed in code with its parameter set in accordance with the terminal type for which the code is being compiled. the htuc code adds ~4 k of rom and ~5 bytes of ram. the htur code adds ~4.6 k of rom. 5.2.1.7 #chan_unit the chan_unit flag provides hooks into the serial communication interface to allow the user to access user defined api commands. in the brooktree evm systems, these api access the channel unit evm boards (channel unit, framer, & liu). please refer to the user interface: code level interface section for details. note: the chan_unit flag may not be used when the #four_loops or #six_loops flags are specified unless the user defined api commands section is modified. 5.2.1.8 #ber_meter the ber_meter flag compiles in the ber meter code. the ber meter code adds ~400 bytes of rom and 1 byte of ram plus an additional 5 bytes of ram for each bit-pump. note that the ber_meter flag cannot be declared when the int_bug compiler flag is specified. see the internal ber meter section in the software application chapter. 5.2.1.9 #erle the erle flag enables the erle diagnostic code. please see appendix c for details.
bt8960 5.0 compiling the source code software user ? s guide 5.2 file names and dependencies 100251b conexant 5-5 preliminary information/conexant proprietary and confidential 5.2.1.10 #initiated_interrupt the initiated_interrupt flag should not be declared. it provides minimal support for some multi-tasking operating systems. multi-tasking operating system use with the activation code is not supported by brooktree. 5.2.1.11 #tdebug the tdebug flag should not be declared. tdebug provides printed text statements about the current status of the bit-pumps during activation. the messages are printed to the 8032 ? s serial port. because of this, tdebug cannot be used when sercom is declared. this flag can be useful for identifying problem areas in the activation sequence. 5.2.1.12 #int_bug the int_bug flag should not be declared. the int_bug flag uses the microprocessor ? s timer and ram instead of the bit-pump ? s internal timers. this was needed in an earlier hdsl bit-pump product. 5.2.2 code modifications the exact location of code sections to be modified are designated by comments of specific form in the source files. the format of these comments is shown in figure 5-1 . these comments contain basic information describing the code section that should be modified (or written). all the modifications are referenced according to their source file name and the order in which they appear in the file. this reference ( ? filename .x ? ) appears both in source file comments and in this manual. figure 5-1. user-modifiable code section format /*---------------------------------------------------------*/ /*>>> user modifiable section user.1 begins <<< */ /*---------------------------------------------------------*/ /* modification description: */ /* write the contents of routine enableuserinterrupts(). */ /* calling this routine should enable all user interrupts. */ /* */ /* reference: */ /* ?bt8960 software user's manual?. */ /*---------------------------------------------------------*/ insert code here /*---------------------------------------------------------*/ /*>>> user modifiable section user.1 ends <<<*/ /*---------------------------------------------------------*/
5.0 compiling the source code bt8960 5.2 file names and dependencies software user ? s guide 5-6 conexant 100251b preliminary information/conexant proprietary and confidential each of the following sections refers to a single code section which must be modified or written. all necessary modifications are covered, and no other changes in the source code should be made. the bit-pump source files that contain modifiable sections are btint.c, init51.c, serint.c, suc.h and user.c . no modifications should be made in any other file. 5.2.2.1 application code the evm application code contains templates (examples) for the main() routine of the application specific code. this main routine should execute both the application tasks and the bt8960 software task. please refer to the bt8960 single-chip 2b1q transceiver evm software manual for details. extreme care must be taken to ensure that the application code (the body of the infinite loop) meets the real-time requirements outlined in the ? software integration ? chapter. the concept is that the time period between successive activations of _btmain() must be kept lower than a specified limit. this requirement puts constraints on the maximum execution time of the application code 5.2.2.2 btint.c.1 code section btint.c.1 should contain the header of the bt8960 interrupt handling routine. the body of the interrupt routine is already written, and should not be modified in any way. however, the routine header syntax is hardware, microprocessor, and compiler specific and must be written for the specific configuration. this routine should be invoked every time a bt8960 interrupt signal is asserted (the bt8960 int pin is an active-low-level triggered signal). this interrupt should be enabled on power-up. it is necessary to ensure the interrupt vector is initialized within the application. when using the borland c compiler, the interrupt routine header is defined as follows: void interrupt _handlebtinterrupt(void) the application specific power-up initialization code should set the _handlebtinterrupt() routine to function as the bt8960 interrupt. 5.2.2.3 init51.c module init51.c contains the intel 8032 microprocessor initialization routines. 5.2.2.4 init51.c.1 code section init51.c.1 should contain the baud rate timer initialization value. the initialization value is dependent on the microprocessor and the crystal frequency.
bt8960 5.0 compiling the source code software user ? s guide 5.2 file names and dependencies 100251b conexant 5-7 preliminary information/conexant proprietary and confidential 5.2.2.5 serint.c.1 code section serint.c.1 should contain the header of the serial interrupt handling routine. the body of the interrupt routine is already written. however, the routine header syntax and some variables are hardware, microprocessor, and compiler specific and must be written for the specific configuration. this routine should be invoked every time a serial interrupt signal is asserted. this interrupt should be enabled on power-up. it is necessary to ensure the interrupt vector is initialized within the application. when using the borland c compiler, the interrupt routine header is defined as follows: void interrupt _handleserialinterrupt(void) the application specific power-up initialization code should set the _handleserialinterrupt() routine to function as the serial interrupt. 5.2.2.6 suc.h.1 code section suc.h.1 should contain the activation interval timer initialization value. the activation_interval macro determines the time to complete the activation state diagram in seconds. the initialization value is dependent on the application symbol rate. this value should be modified so the activation does not prematurely time out during a successful attempt or does not take excessive time to time out during an unsuccessful attempt. the activation interval timer uses the sut4 activation timer (symbol rate / 1024). the _sym_rate api command sets the ? symbol_rate ? variable to symbol rate / 4096. therefore, the value is 4 * desired activation time in seconds * the ? symbol_rate ? variable. example: for a desired activation interval timer of 50. the activation_interval macro needs to be programmed to 4 * 50 * symbol_rate, or 4 * (32 + 16 + 2) * symbol_rate. the macro is implemented as follows: ((((short) symbol_rate << 5) + ((short)symbol_rate << 4) + ((short)symbol_rate)<<1)) << 2) 5.2.2.7 user.c.1 code section user.c.1 should contain the absolute i/o address definitions of the specified number of bt8960 chips as defined by the compiler flags. any value may be defined for non-existent bt8960 chips. the address value depends on the address decoding scheme implemented in the system. the defined address should reflect the value that accesses byte #0 on the bt8960. 5.2.2.8 user.c.2 code section user.c.2 should contain the noise margin calibration table. this table must be modified by the user to be accurate when using different noise source types. refer to appendix b for details.
5.0 compiling the source code bt8960 5.2 file names and dependencies software user ? s guide 5-8 conexant 100251b preliminary information/conexant proprietary and confidential 5.2.2.9 user.c.3 code section user.c.3 contains code that initializes the c pointers used to access the bt8960 chips. the initialization of a pointer with an absolute external address value is done differently in some c compilers. the values of the array should be initialized as follows: _bit_pump[_bit_pump0] should be initialized with the external address bit_pump0_add. _bit_pump[_bit_pump1] should be initialized with the external address bit_pump1_add. _bit_pump[_bit_pump2] should be initialized with the external address bit_pump2_add. in an environment that allows direct assignment of absolute addresses to pointer variables, the user.c.3 code section should be written as follows: _bit_pump[_bit_pump0] = bit_pump0_add; _bit_pump[_bit_pump1] = bit_pump1_add; _bit_pump[_bit_pump2] = bit_pump2_add; when using the borland c compiler, initializing pointer addresses with an absolute value is done using a special c macro in the following way: _bit_pump[_bit_pump0] = mk_fp(bit_pump_segment, bit_pump0_add); _bit_pump[_bit_pump1] = mk_fp(bit_pump_segment, bit_pump1_add); _bit_pump[_bit_pump2] = mk_fp(bit_pump_segment, bit_pump2_add); this assumes all bit-pumps use the same segment, defined by bit_pump_segment , and the bit-pump address constants define the address offset of each bit-pump. 5.2.2.10 user.c.4 the contents of _delay2symbols() routine are application specific. this routine should implement a delay of 2 symbol periods. note: depending on the microprocessor and compiler, entering and exiting this routine may generate the required delay with no need for additional operations or nops. 5.2.2.11 user.c.5 the code section user.c.5 contains the body of the routine _enableuserinterrupts() , and is application specific. this routine, when executed, enables all the non-bt8960 interrupts that are disabled by _disableuserinterrupts() (see user.c.6 ). the bt8960 interrupt is never disabled, so there is no need to enable it. the two routines _disableuserinterrupts() and _enableuserinterrupts() are called by the bt8960 software in critical activation phases.
bt8960 5.0 compiling the source code software user ? s guide 5.2 file names and dependencies 100251b conexant 5-9 preliminary information/conexant proprietary and confidential 5.2.2.12 user.c.6 the code section user.c.6 contains the body of the routine _disableuserinterrupts() , and is application specific. the activation sequence can tolerate 4 ms out of 6 ms of interrupts before performance degradation is noticed. this routine, when executed, should disable all the non-bt8960 interrupts that cause this time criteria to fail. the bt8960 interrupt is always enabled. the _disableuserinterrupts() and _enableuserinterrupts() routines are called by the bt8960 software in critical activation phases. 5.2.2.13 api.c.1 5.2.2.14 api.c.2 5.2.2.15 api.c.3 5.2.2.16 api.h.1 in the api.c and api.h, the channel unit api hooks (found within the chan_unit compiler flags) can be modified to allow the user to define their own api commands. please refer to the user interface: code level interface section for details.
5.0 compiling the source code bt8960 5.2 file names and dependencies software user ? s guide 5-10 conexant 100251b preliminary information/conexant proprietary and confidential
100251b conexant 6-1 preliminary information/conexant proprietary and confidential 6 6.0 user interface this chapter describes the user interface (ui) to the bt8960 hdsl bit-pump software. this interface allows the system designer to have full control over all of bt8960 features, and get status and performance monitoring information from the bit-pump. the interaction between the application and the bt8960 may be achieved in one of two configurations, depending on whether the application software is implemented on the same microprocessor as the bt8960 control software or on a different microprocessor. when only one microprocessor is used in a system, the application should interface the bit-pumps using a code-level application-program interface (api). in a design in which the bt8960 software runs on an 8032 microprocessor, and a second ? host ? microprocessor is used for the application software, a serial communication protocol between the two processors is used to control the bit-pumps. figure 6-1 and figure 6-2 show the two possible control configurations. figure 6-1. two microprocessors implementation non-modified brooktree bt8960 external circuitry data 2 bt8960 external circuitry 1 p bus software 8032 controller uart application implemented software host processor application brooktree chip set and clock data and clock 100251_003
6.0 user interface bt8960 software user ? s guide 6-2 conexant 100251b preliminary information/conexant proprietary and confidential in both configurations described above, the control and monitoring operations are based on a set of commands sent by the application to the bit-pump control software and parameter status sent back to the application. the command set itself is identical in both system configurations. the command structure section describes the structure of commands and status responses, which applies to both ui configurations. the serial communication interface section describes the serial interface message structure and communication protocol which applies to a dual processor system architecture, and the code level interface (api) section describes the api which applies to a single processor architecture. the opcodes and parameters section lists the available commands. appendix a (command set reference) supplies a detailed description of the command set including command syntax, operation, and application hints. figure 6-2. single microprocessor implementation modified brooktree bt8960 external circuitry 2 bt8960 external circuitry 1 p bus software api application software host processor brooktree chip set data and clock data and clock 100251_004
bt8960 6.0 user interface software user ? s guide 6.1 command structure 100251b conexant 6-3 preliminary information/conexant proprietary and confidential 6.1 command structure the structure of all commands is the same. a command is composed of three 1-byte fields: destination, opcode, and data. figure 6-3 shows the structure of a command. the command fields are interpreted according to the following fields. destination field (bits e3 ? e0) ? this field selects the destination to which the command is targeted, according to table 6-1 . opcode field (bits o7 ? o0) ? the opcode field selects the specific command or status request to be executed. the available commands and their opcodes are described in detail in appendix a. the opcodes are also available in c source file api.h, which contains c constant definitions for all opcodes. the opcodes and parameters section contains a list of these opcode constants. data (parameter) field (bits d7 ? d0) ? this field is used in some commands where additional data or parameter selection is required. in commands where there is no need for additional data, zeros should be placed as the data byte to ensure future compatibility. the data field options are also available in c source file api.h , which contains c constant definitions for the available parameters. the ? opcodes and parameters ? section contains a list of these data field constants. figure 6-3. command structure first byte 1 1e3e2e1e0 1 1 0 1 2 3 4 5 6 7 second byte o4 o7 o3 o2 o1 o0 o5 o6 0 1 2 3 4 5 6 7 third byte d4 d7 d3 d2 d1 d0 d5 d6 0 1 2 3 4 5 6 7 100251_005 table 6-1. destination field specification e3 e2 e1 e0 destination 0000 bt8960 #0 0001 bt8960 #1 0010 bt8960 #2 0011 bt8960 #3 0100 bt8960 #4 0101 bt8960 #5
6.0 user interface bt8960 6.1 command structure software user ? s guide 6-4 conexant 100251b preliminary information/conexant proprietary and confidential the set of commands is divided into three logical groups: control commands, status request commands, and special messages. the first group includes all commands that control the operation of the bit-pump and set different parameters. the second group includes commands that request status values or monitoring information from the bit-pump. in response to a status request command, a 1-byte data word is returned to the application supplying the required information. the special messages include the acknowledge message (applies only to serial communication ui).
bt8960 6.0 user interface software user ? s guide 6.2 serial communication interface 100251b conexant 6-5 preliminary information/conexant proprietary and confidential 6.2 serial communication interface in a dual processor system (see figure 6-1 ), the application controls the bit-pumps using a serial communication message transfer protocol. the protocol is based on the command set described in appendix a, and the command structure as described in the command structure section, with additional requirements for this type of interface. 6.2.1 communication protocol the 8032 communicates with the host processor using a standard uart interface. the physical connection includes two lines: rxd (8032 pin 10) and txd (8032 pin 11). the data is transferred in an asynchronous format: 9600 baud, 1 start bit, 8 data bits, 1 stop bit, no parity. to select a separate baud rate, refer to the compiling the source code ? chapter. 6.2.2 message transfer protocol the application sends a command to any of the bit-pumps in the system by transmitting a message over the serial communication channel. every command that is correctly received and decoded by the 8032 is acknowledged by sending a special acknowledge message back to the application. in response to a status request command, the 8032 also sends a status response message that contains the information requested. the 8032 is guaranteed to acknowledge a received message within 200 ms, except during activation where larger delays (up to 2 seconds) may be present. the host processor will usually retransmit a message that was not acknowledged within this time limit. no new message should be sent by the host processor before the previous one was acknowledged unless the time limit has been exceeded. a status request message requiring information from the bit-pump will first be acknowledged, and only then will a response message containing the requested information be sent to the host processor.
6.0 user interface bt8960 6.2 serial communication interface software user ? s guide 6-6 conexant 100251b preliminary information/conexant proprietary and confidential 6.2.3 message structure all messages are 4 bytes long. figure 6-4 shows the structure of a message sent by the host processor to the 8032. the first 3 bytes are the command bytes, as described in the command structure section. the fourth byte (the last transmitted byte) contains checksum information that is a function of the first 3 bytes (see the checksum function subsection for checksum function details). the checksum considerably reduces the probability of the 8032 misinterpreting an incoming message. when the 8032 receives a status request command, it responds (after acknowledging the command) by sending a status message to the host processor. the structure of a status message is similar to the structure of a host-to-8032 message, and is shown in figure 6-5 . the first 2 bytes are identical to the first 2 bytes of the corresponding status request command. bits s3 ? s0 of the first byte are interpreted, according to table 6-1 , as the source bit-pump for the status response. the second opcode byte (bits o7 ? o0) contains the opcode of the command that requested the information. the third byte (bits d7 ? d0) contains the requested information. the fourth byte (bits cs7 ? cs0) is the checksum value, calculated according to the formula described in the checksum function subsection. figure 6-4. host processor to 8032 message structure first byte 1 1e3e2e1e0 1 1 0 1 2 3 4 5 6 7 second byte o4 o7 o3 o2 o1 o0 o5 o6 0 1 2 3 4 5 6 7 third byte d4 d7 d3 d2 d1 d0 d5 d6 0 1 2 3 4 5 6 7 fourth byte cs4 cs7 cs3cs2 cs1cs0 cs5 cs6 0 1 2 3 4 5 6 7 100251_006
bt8960 6.0 user interface software user ? s guide 6.2 serial communication interface 100251b conexant 6-7 preliminary information/conexant proprietary and confidential 6.2.4 checksum function for every command sent by the host processor, a checksum function value is calculated and sent as the fourth byte of the message. this value is calculated using the following formula: cs = (byte #1) | (byte #2) | (byte #3) | (0xaa); where ? | ? denotes a bit-wise exclusive-or operation, and 0xaa is the binary byte 10101010. the same rule is used by the 8032 to calculate the checksum byte of status message sent to the host processor. figure 6-5. 8032 to host processor message structure first byte 1 1s3s2s1s0 1 1 0 1 2 3 4 5 6 7 second byte o4 o7 o3 o2 o1 o0 o5 o6 0 1 2 3 4 5 6 7 third byte d4 d7 d3 d2 d1 d0 d5 d6 0 1 2 3 4 5 6 7 fourth byte cs4 cs7 cs3cs2 cs1cs0 cs5 cs6 0 1 2 3 4 5 6 7 100251_007
6.0 user interface bt8960 6.3 code level interface (api) software user ? s guide 6-8 conexant 100251b preliminary information/conexant proprietary and confidential 6.3 code level interface (api) the code level api is intended for applications integrating the bit-pump control software in a single microprocessor system (see figure 6-2 ). in such a configuration, the application issues a command and gets information from the bit-pumps by calling a specific routine. to issue any one of the control commands (see the control commands section in appendix a), the application should call the _btcontrol() function. to issue a status request command (see the serial communication interface section), the _btstatus() function should be called. 6.3.1 _btcontrol() the _btcontrol() routine is used to issue any one of the control commands specified in the control commands section in appendix a. use unsigned char _btcontrol(unsigned char destination, unsigned char opcode, unsigned char parameter); description the destination, opcode, and data parameters correspond to the three command bytes as described in the command structure section. the opcode field must contain a value corresponding to one of the control commands specified in the control commands section in appendix a effect the required command is executed on the bit-pump designated by the destination parameter (unless an error condition occurred). return value _pass (0x00) indicates a successfully interpreted command. the command is executed. _fail (0x01) indicates an error condition. the command is not executed. an error condition may be caused by an illegal value in any one of the command fields. example to configure bit-pump #2 as a remote terminal (htu-r), execute the following routine call: _btcontrol(_bit_pump2, _terminal_type, _htur);
bt8960 6.0 user interface software user ? s guide 6.3 code level interface (api) 100251b conexant 6-9 preliminary information/conexant proprietary and confidential 6.3.2 _ btstatus() the _btstatus() routine is used to issue any one of the status request commands specified in the status request commands section in appendix a. 6.3.3 user defined api commands - channel unit & framer the code level api structure provides hooks to allow the user to access their own user defined api commands. in the dual processor mode, this allows the user to use the serial communication interface message protocol to handle the user defined api commands. the user then only needs to create (define) their own api commands. the bit-pump code provides hooks to access the channel unit and framer api commands, these are to support the brooktree evm systems. however, the user may rename, add, or delete to these hooks. _cucontrol() _custatus() _framercontrol() _framerstatus() use unsigned char _btstatus(unsigned char destination, unsigned char opcode, unsigned char parameter, char indication); description the destination, opcode, and data parameters correspond to the three command bytes as described in the command structure section. the opcode field must contain a value corresponding to one of the status request commands specified in the special messages section in appendix a. effect the status parameter is set to the required value (unless an error condition occurred). return value _pass (0x00) indicates a successfully interpreted command. the value of the status parameter is correctly set. example _fail (0x01) indicates an error condition. the value of the status parameter has no meaning and should be ignored. an error condition may be caused by an illegal value in any of the command fields.
6.0 user interface bt8960 6.3 code level interface (api) software user ? s guide 6-10 conexant 100251b preliminary information/conexant proprietary and confidential these function descriptions are identical to the _btcontrol() and _btstatus() functions. the channel unit evm has the following destination field values (see also table 3): the channel unit and framer destination fields are numbered 3 to 7 to maintain compatibility with existing brooktree evm system and support programs. however, these destination fields will cause a conflict when the #four_loops or #six_loops complier flags are specified, since the #four_loops or #six_llps flags specify the destination field between (0 and 3) or (0 to 5). if the user wishes to use the #chan_unit compiler flag with the #four_loops or #six_loops flags, then the channel unit destination fields must be modified. note: the brooktree evms are typically compiled with the #three_loops and #chan_unit complier flags table 6-2. destination field values e3 e2 e1 e0 destination #define 0011channel unit common sections _cu_common 0100channel unit hdsl loop #1 specific _cu_chan1 0101channel unit hdsl loop #2 specific _cu_chan2 0110channel unit hdsl loop #3 specific _cu_chan3 0111e1/t1 framer and liu _framer
bt8960 6.0 user interface software user ? s guide 6.4 opcodes and parameters 100251b conexant 6-11 preliminary information/conexant proprietary and confidential 6.4 opcodes and parameters the source file api.h contains c constant definitions for the opcodes of all commands, and for the possible data field values of commands that use this field. note: these definitions should be employed in application code for the bt8960 ui. table 6-3 lists the available commands, each with its corresponding c constant opcode and parameter definitions (where applicable). see appendix a for details on command use, operation, and parameter setting. table 6-3. user interface command summary (1 of 3) command name opcode c constants data field options data field c constants terminal type _terminal_type htu-r htu-c _htur _htuc analog agc configuration _analog_agc_config no agc 2-level discrete agc 4-level discrete agc 6-level discrete agc _no_agc _two_level_agc _four_level_agc _six_level_agc start-up sequence source _startup_seq_ source internal start-up sequence external start-up sequence _internal _external transmit scrambler _transmit_scr scramble tx symbols do not scramble tx symbols _activate_scr _bypass receive descrambler _receive_descr descramble rx symbols do not descramble rx symbols _activate_descr _bypass data transfer format _framer_format parallel data, clock outputs parallel data, clock inputs serial data serial data, sign & magnitude swapped _parallel_master _parallel_slave _serial _serial_swap other side bt8960 _bt_other_side bt8960 bit-pump used on other terminal non-bt8960 bit-pump on other terminal _bt _no_bt lost time period _lost_time_period 1-byte unsigned integer bit-pump on/off _system_config bit-pump on bit-pump off _present _not_present transmit external data _transmit_ext_data 0 activate _activate 0 deactivate _deactivate 0
6.0 user interface bt8960 6.4 opcodes and parameters software user ? s guide 6-12 conexant 100251b preliminary information/conexant proprietary and confidential test mode _test_mode _exit_test_mode _analog_loopback _near_loopback _far_loopback _isolated_pulse_plus3 _isolated_pulse_plus1 _isolated_pulse_minus1 _isolated_pulse_minus3 _four_level_scr _two_level_scr _vcxo_nominal _vcxo_min _vcxo_max _internal_analog_ loopback _external_analog_ loopback symbol rate _sym_rate 1-byte unsigned integer reset _reset_system 0 enable/disable non-linear ec _operate_nlec enable nl ec operation disable nl ec operation _nlec_on _nlec_off write transmitter gain register _write_tx_gain 1-byte signed integer input signal level _slm 0 input dc offset _dc_meter 0 far-end signal attenuation _felm 0 noise margin _nmr 0 vcxo control voltage _vcxo_control_ voltage 0 bit-pump status _startup_status 0 aagc control bits value _aagc_value 0 read linear ec coefficient _lec_coeff coefficient index read nl ec coefficient _nlec_coeff coefficient index read eq coefficient _eq_coeff coefficient index read dfe coefficient _dfe_coeff coefficient index table 6-3. user interface command summary (2 of 3) command name opcode c constants data field options data field c constants
bt8960 6.0 user interface software user ? s guide 6.4 opcodes and parameters 100251b conexant 6-13 preliminary information/conexant proprietary and confidential software / chip versions _version major sw & bitpump version major sw version minor sw version bitpump type & version _hw_sw_versions _major_sw_version _minor_sw_version _hw_type_versions bit-pump present _bit_pump_present 0 self-test _self_test 0 read bt8960 register _register bt8960 register address bit-pump configuration _configuration request low byte of user setup request high byte of user setup request lost time period information request symbol rate information _user_setup_low_byte _user_setup_high_byte _lost _bit_rate stage number _stage_number 0 read transmitter gain register _read_tx_gain request tx calibration value request tx gain value _calibration _gain table 6-3. user interface command summary (3 of 3) command name opcode c constants data field options data field c constants
6.0 user interface bt8960 6.4 opcodes and parameters software user ? s guide 6-14 conexant 100251b preliminary information/conexant proprietary and confidential
100251b conexant a-1 preliminary information/conexant proprietary and confidential a appendix a command set reference this appendix contains a reference guide to the bt8960 user interface command set. all available commands are listed, giving information on command use, application, syntax, and options. the set of commands is divided into three groups: 1. control commands ? control the operation modes of the bit-pump and set various parameters. 2. status request commands ? inquire for status and monitoring information from the bit-pump. a 1-byte response containing the required information is transferred back. 3. special commands. a.1control commands for each command, a description of its operation, opcode, and options is given. commands that select bit-pump operational options and set bit-pump parameters have their default value underlined . the default values are also given in the setting bit-pump parameters section. a.1.1 terminal type sets the bit-pump terminal type. in any operational hdsl system, a bit-pump on one side of the loop should be defined to be an htu-c (hdsl terminal unit ? central office side) and the bit-pump on the other side should be defined to be an htu-r (remote terminal). the two terminal types differ in their activation procedure, timing recovery mechanism, scrambler/descrambler taps, and more. terminal type must be properly defined prior to any activation operation.
appendix a command set reference bt8960 a.1 control commands software user ? s guide a-2 conexant 100251b preliminary information/conexant proprietary and confidential in a multipair system, each bit-pump may be individually set as an htu-c or htu-r (although in most implementations all bit-pumps will be set to the same terminal type). a.1.2 analog agc configuration informs the bit-pump software of the analog agc configuration implemented in the design. opcode numeric value c constant (defined in file api.h) 0x01 _terminal_type options option description data field c constant (api.h) htu-c central office terminal 0x00 _htuc htu-r remote terminal 0x01 _htur opcode numeric value c constant (defined in file api.h) 0x02 _analog_agc_config options option description data field value c constant (api.h) no agc no analog agc is implemented, and constant receiver gain is used. 0x00 _no_agc 2-step agc discrete analog agc is used, with two possible gain levels. the gain value is controlled by pin agc[0]. 0x01 _two_level_agc 4-step agc discrete analog agc is used, with four possible gain levels. the gain value is controlled by pins agc[0] (lsb) and agc[1]. 0x02 _four_level_agc 6-step agc discrete analog agc is used, with six possible gain levels. the gain value is controlled by pins agc[0] (lsb), agc[1], and agc[2]. 0x03 _six_level_agc
bt8960 appendix a command set reference software user ? s guide a.1 control commands 100251b conexant a-3 preliminary information/conexant proprietary and confidential the bt8960 bit-pump internally supports six different analog agc configurations as shown in table a-1 . three internal gain control signals are supplied by the bt8960. in a 2-level discrete agc configuration, pin again[0] is used to select between two discrete gain values, where a 0 selects the lower gain. in a 4-level discrete agc configuration, pin again[0] and again[1] are used to select between four discrete gain values, again[0] being the lsb. a ? 00 ? selects the lowest gain. in a 6-level discrete agc configuration, pin again[0], again[1] and again[2] are used to select between six discrete gain values, again[0] being the lsb. a ? 000 ? selects the lowest gain. in a 6-level aagc implementation, the recommended relative gain settings are 0 db, 3 db, 6 db, 9 db, 12 db, and 15 db. in a 4-level aagc implementation, the recommended relative gain settings are 0 db, 3 db, 6 db, and 9 db. in a 2-level aagc implementation, the recommended relative gain settings are 0 db and 6 db. when no agc is implemented, the fixed gain is referred to as the 0 db level. note: the 6-level agc setting should be set for optimal performance. a.1.3 start-up sequence source selects the the source of activation sequences to be external or internal. the bt8960 provides for internally generated activation sequences that may be used in a complete stand-alone transceiver implementation. the internally generated activation sequences are 2- or 4-level scrambled 1s, with no hdsl framing information. these sequences do not meet the standard activation requirements which require hdsl framing information to be included in the activation sequences. table a-1. bt8960 again settings c constants numeric value again[2] again[1] again[0] _again0db 0 0 0 0 _again3db 100 1 _again6db 2 0 1 0 _again9db 3 0 1 1 _again12db 4 1 0 0 _again15db 5 1 0 1
appendix a command set reference bt8960 a.1 control commands software user ? s guide a-4 conexant 100251b preliminary information/conexant proprietary and confidential if a framed activation sequence is required, it must be supplied prior to any activation operation and the start-up sequence source must be set to external. only a 4-level sequence need be supplied. the bit-pump ignores the magnitude bit during the initial 2-level transmission. note: when the internal option is specified, the _transmit_ext_data command must be called when the activation process is successfully completed. a.1.4 transmit scrambler activates or bypasses the internal transmit scrambler. the internal transmit scrambler (and receive descrambler) may be used for stand-alone operation of the bit-pump. when activated, all incoming data is scrambled and then converted to quaternary symbols for transmission. opcode numeric value c constant (defined in file api.h) 0x03 _startup_seq_source options option description data field c constant (api.h) external start-up sequence start-up sequences are supplied externally. a 4-level activation sequence must be supplied before activation is initiated. 0x00 _external internal start-up sequence start-up sequences are generated internally. these sequences are 2/4 level scrambled 1 ? s, with no hdsl framing. 0x01 _internal opcode numeric value c constant (defined in file api.h) 0x04 _transmit_scr options option description data field c constant (api.h) bypass the transmit scrambler is not used and the symbols supplied by the application are transmitted with no change. 0x00 _bypass active the transmit scrambler is activated, and the bit stream supplied by the application is scrambled on chip before being transmitted. standard scrambler taps are used (according to terminal type setting). the tx scrambler is operated (when turned on) only during 4-level transmission, i.e., during 4-level activation transmission and during normal operation. 0x01 _activate_scr
bt8960 appendix a command set reference software user ? s guide a.1 control commands 100251b conexant a-5 preliminary information/conexant proprietary and confidential a.1.5 receive descrambler activates or bypasses the internal receive descrambler. the internal receive descrambler may be used for stand-alone operation of the bit-pump. when activated, all detected symbols are converted to bits and descrambled, prior to being transferred to the data output pins. note that all received bits are descrambled, including framing and overhead bits. opcode numeric value c constant (defined in file api.h) 0x05 _receive_descr options option description data field c constant (api.h) bypass the receive descrambler is not used and the detected symbols are supplied with no change. 0x00 _bypass active the receive descrambler is activated and the received bit stream is descrambled before being transferred. 0x01 _activate_descr
appendix a command set reference bt8960 a.1 control commands software user ? s guide a-6 conexant 100251b preliminary information/conexant proprietary and confidential a.1.6 data transfer format selects the format in which data is transferred between the bt8960 and the application. this option has no effect on data value, only the data transfer format is affected. different data transfer formats allow for different schemes of framer bit-pump clock distribution. for more details, see the bt8960 datasheet. opcode numeric value c constant (defined in file api.h) 0x06 _framer_format options option description data field c constant (api.h) parallel data, clock outputs the bt8960 supplies a baud rate clock signal (qclk) that times the data transfer in both the receive and transmit directions. received quats are being transferred to the framer via the rq[0], rq[1] pins. transmitted quats are being transferred to the bit-pump via the tq[0], tq[1] pins. 0x00 _parallel_master parallel data, clock inputs a baud rate clock signal (rbclk) is supplied that times the data transfer in the receive direction. also supplied is a separate baud rate clock (tbclk) that times the data transfer in the transmit direction. received and transmitted quats are transferred via the tq and rq signals, as in ? parallel with clock outputs ? mode. the rbclk and tbclk signals must be a derivative of the bt8960 ? s 16x clock at an arbitrary phase. 0x01 _parallel_slave serial data the bt8960 supplies a baud rate clock (on the qclk pin) and a bit rate clock (on the rq[0] pin) that time the data transfer in both receive and transmit directions. the received and transmitted quats are transferred serially, each on a single line, via the rq[1] and tq[1] pins. the 2b1q magnitude bit is aligned to qclk low and the 2b1q sign bit is aligned to qclk high. 0x02 _serial serial swap data the bt8960 supplies a baud rate clock (on the qclk pin) and a bit rate clock (on the rq[0] pin) that time the data transfer in both receive and transmit directions. the received and transmitted quats are transferred serially, each on a single line, via the rq[1] and tq[1] pins. the 2b1q magnitude bit is aligned to qclk high and the 2b1q sign bit is aligned to qclk low. this format satisfies the etsi/ansi requirements for output quat orientation 0x03 _serial_swap
bt8960 appendix a command set reference software user ? s guide a.1 control commands 100251b conexant a-7 preliminary information/conexant proprietary and confidential a.1.7 other side bt8960 in a system where both terminals use bt8960 bit-pumps, several activation operations can be performed more efficiently relative to the standard requirements. this command is used to inform the bt8960 software that the other terminal uses a bt8960 bit-pump. a.1.8 lost time period an on-chip timer is restarted when a loss of signal condition is detected. when this timer reaches a pre-defined value, the lost status bit is turned on. once turned on, the status bit will not reset (even if there is no longer a los condition). the lost indication is cleared only when an activate or reset command is issued. the lost mechanism is active only after a deactivate command is issued. thus, during activation or normal operation, the lost status is never set. this implementation is in correspondence with the t1e1/etsi hdsl activation state diagrams. the lost time interval is programmable in the range 0 ? 31 seconds with a resolution of 1/10 second. the value of the lost status bit may be checked using the bit-pump status command. opcode numeric value c constant (defined in file api.h) 0x07 _bt_other_side options option description data field c constant (api.h) other side unknown the terminal on the other loop end is not known to use the bt8960. 0x00 _no_bt other side bt8960 the terminal on the other side of the loop employs a bt8960. 0x01 _bt opcode numeric value c constant (defined in file api.h) 0x08 _lost_time_period options option description data field c constant (api.h) lost time period 1-byte unsigned integer x. the lost time period is set to x/10 seconds. default value: 10 = 1 second. x
appendix a command set reference bt8960 a.1 control commands software user ? s guide a-8 conexant 100251b preliminary information/conexant proprietary and confidential a.1.9 bit-pump on/off informs the bt8960 software which bit-pumps are active in the system. setting a bit-pump state to off causes the bt8960 software to put the chip in a ? power-down ? mode and ignore any further control commands issued to this bit-pump, other than bit-pump on/off. all bit-pumps that are intended to be activated should be turned on prior to any other control operation. the bit-pumps are numbered from 0 to 5. any of the bit-pumps may be used in a system (note that a hardware implementation may include, for example, three bit-pumps, only two of which are turned on). a.1.10 transmit external data this command should be used only when the activation sequence source is internal. when issued, this command causes the bit-pump to start transmission of externally supplied data symbols. this command should be issued upon the successful completion of activation, which is determined by the application, based on bit-pump and framer status responses. the transmitted data should be supplied to the bit-pump prior to issuing this command. avoid situations where a long stream of constant value symbols is transmitted. opcode numeric value c constant (defined in file api.h) 0x09 _system_config options option description data field c constant (api.h) off turn bit-pump off 0x00 _not_present on turn bit-pump on 0x01 _present opcode numeric value c constant (defined in file api.h) 0x0a _transmit_ext_data options option description data field c constant (api.h) none 0x00
bt8960 appendix a command set reference software user ? s guide a.1 control commands 100251b conexant a-9 preliminary information/conexant proprietary and confidential a.1.11 activate initiates the activation process. on an htu-c terminal, this command causes 2-level activation sequence transmission to begin. on an htu-r terminal, this command causes the bit-pump to wait for the detection of an incoming signal, and continue with the activation process when such a signal is detected. the activation process itself is fully automatic. an application may inquire about the activation status, snr, etc., but otherwise no actions are required. a.1.12 deactivate turns the transmitter off and stop all activation operations regardless of the current bit-pump status. the bit-pump goes to an idle state, where it awaits further commands. issuing the deactivate command enables the lost mechanism (see the lost time period command). if issued during normal operation, the receiver continues to function properly (useful for test purposes). opcode numeric value c constant (defined in file api.h) 0x0b _activate options option description data field c constant (api.h) none 0x00 opcode numeric value c constant (defined in file api.h) 0x0c _deactivate options option description data field c constant (api.h) none 0x00
appendix a command set reference bt8960 a.1 control commands software user ? s guide a-10 conexant 100251b preliminary information/conexant proprietary and confidential a.1.13 test mode operates the bit-pump in special test modes. these modes include maintenance operating modes and loopback configurations. to execute a bit-pump self-test procedure, use the self-test status request command. to turn off any of the special test modes, use the test mode command with an _exit_test_mode (0 value) parameter. all test modes except the two digital loopback modes require, after exiting the test mode, a complete activation procedure to be repeated (assuming normal operation is required). when exiting all these test modes (by issuing the test mode command with a 0 value parameter), the bit-pump is initialized to a reset state, and goes to the idle state, where it awaits further commands. the two digital loopback test modes do not interfere with the operation of the bit-pump, and only affect the received/transmitted symbol stream. therefore, operating the bit-pump in a digital (near/far) loopback during normal operation will not cause loss of synchronization. exiting one of these two test modes will turn off the loopback operation, allowing for normal data transfer to continue with no need for a restart. table a ? a-2 summarizes the action taken when exiting different test modes. note: when exiting a ? digital far loopback ? mode, the transmitted symbol sequence source depends on the setting of the ? internal/external activation sequence ? flag. table a-2. exiting test modes test mode action taken when exiting test mode how to go back to normal data transfer (1) digital near loopback rx symbol stream (bit-pump to framer) is sent back to be the detected symbols sequence. exit test mode. digital far loopback external activation sequence mode: transmit external data (tx scrambler is operated/bypassed according to the transmit scrambler mode setting). exit test mode. internal activation sequence mode: transmit internally generated 4-level scrambled 1 ? s sequence. exit test mode. issue transmit external data command to start transmitting the externally supplied (payload) data. all other test modes bit-pump initialized to a reset state, and goes to an idle state. complete activation operation is required. (1) assuming normal data transfer took place before issuing test mode opcode numeric value c constant (defined in file api.h) 0x0d _test_mode
bt8960 appendix a command set reference software user ? s guide a.1 control commands 100251b conexant a-11 preliminary information/conexant proprietary and confidential options option description data field c constant (api.h) exit test mode cancel test mode. see table a-1. 0x00 _exit_test_mode external analog loopback transmit the externally supplied tx symbols. use the echo signal as a ? received ? signal and detect the symbols using the standard equalizer. 0x01 _analog_loopback digital ? near ? loop back tx symbols supplied to the bit-pump by the framer are looped back as the rx symbols going from the bit-pump to the framer. useful for testing the framer and the framer/bit-pump connection. 0x02 _near_loopback digital ? far ? loop back detected rx symbols are transmitted back on the loop. useful for testing full 2-way transmission over a loop. (1) 0x03 _far_loopback transmit isolated +3 pulse transmit (repeatedly) an isolated +3 level pulse. useful for testing the transmitted pulse shape. 0x04 _isolated_pulse_plus3 transmit isolated +1 pulse transmit (repeatedly) an isolated +1 level pulse 0x05 _isolated_pulse_plus1 transmit isolated ? 1 pulse transmit (repeatedly) an isolated ? 1 level pulse 0x06 _isolated_pulse_minus1 transmit isolated ? 3 pulse transmit (repeatedly) an isolated ? 3 level pulse 0x07 _isolated_pulse_minus3 continuous 4-level transmission continuous transmission of a 4-level scrambled 1s sequence (internally generated). useful for measuring transmitted power and spectral shape. 0x08 _four_level_scr continuous 2-level transmission continuous transmission of a 2-level scrambled 1s sequence (internally generated). 0x09 _two_level_scr set nominal vcxo frequency set vcxo control word to its nominal value. useful for measuring vcxo center frequency. 0x0a _vcxo_nominal set minimum vcxo frequency set vcxo control word to its minimum value. 0x0b _vcxo_min set maximum vcxo frequency set vcxo control word to its maximum value. 0x0c _vcxo_max internal analog loop back transmits the externally supplied tx symbols out the txp and txn pins and detects the symbols on the hybrid inputs (rxbp, rxbn), the receive inputs (rxp and rxn) are bypassed. 0x0d _internal_analog_ loopback isolated analog loop back the externally supplied tx symbols are internally looped back in the bt8960. the transmitter (txp and txn) is turned off (silent). 0x0e _isolated_analog_ loopback (1) the operation of a digital ? far ? loopback requires activating the bt8960 internal tx scrambler and rx descrambler.
appendix a command set reference bt8960 a.1 control commands software user ? s guide a-12 conexant 100251b preliminary information/conexant proprietary and confidential a.1.14 symbol rate informs the bt8960 software of the bit-pump symbol rate. this value is used to convert seconds to symbols when absolute time interval measurements are performed using the symbol rate on-chip timers. this value must be programmed for proper bit-pump operation. note: if the _sym_rate command is issued, then it must be called immediately after the _system_config on command. the _sym_rate command sets the pll clock center frequency. there is a potential for the bit-pump registers to get corrupted when the pll clock frequency is changed. the _sym_rate command initializes the bit-pump registers to the default state after writing the pll clock center frequency. therefore, the user must issue their application specific api command values after the _sym_rate command is issued. a.1.15 reset loads bit-pump microcode, reset all bit-pump internal registers, and set all user-programmable options to their default values. after issuing a reset, all non-default user-programmable options should be reprogrammed using the appropriate commands. the reset operation is automatically performed when turning a bit-pump on using the bit-pump on/off command. therefore, under normal operating conditions, there should be no need for the reset command. opcode numeric value c constant (defined in file api.h) 0x0e _sym_rate options option description data field c constant (api.h) symbol rate 1-byte unsigned integer x, calculated according to: x=symbol rate / 4096. default value: 35=144 ks/sec. x opcode numeric value c constant (defined in file api.h) 0x0f _reset_system options option description data field c constant (api.h) none 0x00
bt8960 appendix a command set reference software user ? s guide a.1 control commands 100251b conexant a-13 preliminary information/conexant proprietary and confidential a.1.16 operate non-linear ec selects between operating or disabling of the bt8960 non-linear echo canceler. note: the non-linear echo canceler is not functional in bt8960 rev a & b and should not be activated. a.1.17 write transmitter gain writes the transmitter gain register. the transmitter gain register is a 4-bit, 2 ? s complement value. the upper 4 bits of this field are ignored. the tx gain adjusts the nominal transmit power of the bt8960. the tx gain ranges from ? 1.6 dbm (1000b) to +1.4 dbm (0111b) of the nominal transmit power level. opcode numeric value c constant (defined in file api.h) 0x11 _operate_nlec options option description data field c constant (api.h) disable nl ec nl ec is not activated and not used 0x00 _nlec_off enable nl ec nl ec operates normally 0x01 _nlec_on opcode numeric value c constant (defined in file api.h) 0x13 _write_tx_gain options option description data field c constant (api.h) tx gain 4-bit, 2 ? s complement integer. value
appendix a command set reference bt8960 a.1 control commands software user ? s guide a-14 conexant 100251b preliminary information/conexant proprietary and confidential a.1.18 tip/ring reversal reverses the tip/ring polarity on the received signal. however, the bt8960 does not reverse the tip/ring polarity on the transmitted signal. in addition, the bt8960 does not provide the ability to detect when tip/ring reversal is necessary. this command is useful in applications where a framer has the ability to detect tip/ring reversal but can not correct the tip/ring reversal. since this command only reverses the received signal, it is necessary to call this command on both the central and remote terminals when tip/ring reversal is detected. note: this command is only supported by versions 2.0+. a.1.19 ber meter start activates the ber meter. the bit-pump is set to transmit an internal 4-level scrambled ones pattern. the enabled bit is set and the bit_errors & meter_intervals variables are reset to 0. this command should only be called during the bit-pump ? s normal operation. note: this command is only supported by versions 2.0+. opcode numeric value opcode 0x14 _reverse_tip_ring options option description data field c constant (defined in file api.h) tip/ring normal sets the tip/ring polarity on the received signal to normal (not-reversed). 0x00 tip/ring reverse reverses the tip/ring polarity on the received signal. 0x01 opcode numeric value c constant (defined in file api.h) 0x15 _ber_meter_start
bt8960 appendix a command set reference software user ? s guide a.1 control commands 100251b conexant a-15 preliminary information/conexant proprietary and confidential a.1.20 ber meter stop deactivates the ber meter. the bit-pump is set to transmit external 4-level data, the transmit scrambler is set based on the current _transmit_scr api setting. the enabled bit is turned off. the bit_errors and meter_intervals variables are unmodified so they can be still read. note: this command is only supported by versions 2.0+. options option description data field c constant (defined in file api.h) none 0x00 opcode numeric value c constant (defined in file api.h) 0x16 _ber_meter_stop options option description data field c constant (defined in file api.h) none 0x00
appendix a command set reference bt8960 a.2 status request commands software user ? s guide a-16 conexant 100251b preliminary information/conexant proprietary and confidential a.2status request commands status request commands are used to get performance monitoring information from the bit-pump. these commands do not affect bit-pump operation in any way. the bit-pump response to all status request commands is a 1-byte response. for each status request command, the type and format of information supplied, and the command opcode and the options are described. a.2.1 input signal level requests the level of the average signal level at the adc input. note: the signal at the adc input consists of a large transmitted echo component, and a smaller far-end signal component. thus, no cable attenuation data may be extracted from this information. a.2.1.1 bit-pump response unsigned integer x, 0 x 255, relative to the average absolute value of the adc input signal. the measurement scale is such that a value of 255 corresponds to the adc positive full scale value. a.2.2 input dc offset requests the value of the average dc level at the adc input. note: any level of input dc offset is digitally canceled on-chip, but large dc offsets (>2% of full scale) may degrade performance because of the reduction in effective adc dynamic range. opcode numeric value c constant (defined in file api.h) 0x80 _slm options option description data field c constant (api.h) none 0x00
bt8960 appendix a command set reference software user ? s guide a.2 status request commands 100251b conexant a-17 preliminary information/conexant proprietary and confidential a.2.2.1 bit-pump response signed integer x, ? 128 x 127, relative to the average dc offset per adc sample. the measurement scale is such that the actual dc offset in units of adc lsb is 32x. in case the actual dc offset is outside the representable range ( ? 4096 to 4095), the nearest representable value will be used. a.2.3 far-end signal attenuation requests a value of the far-end signal attenuation. this value is based on measuring the average far-end signal level after echo cancellation. the result is calibrated to represent the overall signal power attenuation over the cable in db. it is also calibrated for an analog gain value of 0 db, with an absolute gain value as implemented in brooktree ? s hdsl evm system. when using a different analog gain value, or an aagc gain selection other than 0 db, the signal attenuation result must be scaled accordingly. for example, if an analog gain value of 6 db is used, the actual signal attenuation is 6 db larger than reported. note also that this value depends on the transmitted power at the far-end side, and is calibrated for the nominal 13.5 dbm value. a.2.3.1 bit-pump response 1-byte unsigned integer x, 0 x 255, indicating the overall signal power attenuation, in units of 0.5 db. for example, a value of 60 means total cable attenuation of 30 db. opcode numeric value c constant (defined in file api.h) 0x81 _dc_meter options option description data field c constant (api.h) none 0x00 opcode numeric value c constant (defined in file api.h) 0x82 _felm options option description data field c constant (api.h) none 0x00
appendix a command set reference bt8960 a.2 status request commands software user ? s guide a-18 conexant 100251b preliminary information/conexant proprietary and confidential a.2.4 noise margin requests a value of the noise margin (nmr) of the receiver. the noise margin is defined as the maximum tolerable increase in external noise power that still allows for ber of less than 1e ? 7. the value is based on measuring the average absolute level of the noise at the input to the slicer. in order to get a stable response, it is recommended that the average of 10 noise margin readings is used to reduce the statistical measurement error. a.2.4.1 bit-pump response 1-byte signed integer x, ? 128 x 127, indicating the noise margin in units of 0.5 db. for example, a value of ? 8 means a noise margin of ? 4 db. a.2.5 timing recovery control requests a value of the timing recovery control circuit. this value indicates the timing recovery frequency relative to its center frequency, which does not necessarily equal the nominal transmission frequency. on an htu-c terminal, this response will always be zero since the control circuit is set to its nominal value. on an htu-r terminal, this value gives an estimate of the frequency offset relative to the center frequency. the relation of the given value with the frequency offset in hz depends on the timing recovery ? s slope. note: this replaces the _vcxo_control_voltage api command found in existing brooktree hdsl products. opcode numeric value c constant (defined in file api.h) 0x83 _nmr options option description data field c constant (api.h) none 0x00 opcode numeric value c constant (defined in file api.h) 0x84 _timing_recovery_control
bt8960 appendix a command set reference software user ? s guide a.2 status request commands 100251b conexant a-19 preliminary information/conexant proprietary and confidential a.2.5.1 bit-pump response signed integer x, ? 128 x 127, indicating the 8 msbs of the timing recovery control word. a.2.6 bit-pump status requests bit-pump status. the status bits are designated i0 (lsb) to i7 (msb), and interpreted according to table a-2. options option description data field c constant (api.h) none 0x00 opcode numeric value c constant (defined in file api.h) 0x85 _startup_status options option description data field c constant (api.h) none 0x00
appendix a command set reference bt8960 a.2 status request commands software user ? s guide a-20 conexant 100251b preliminary information/conexant proprietary and confidential a.2.6.1 bit-pump response a.2.7 read linear echo canceler coefficient reads a specified linear echo canceler coefficient. table a-3. status bits status bit indicates value = 0 value = 1 i0 (lsb) los: a los condition is defined as the absence of a far-end signal at the receiver input. no los condition los condition i1 lost: a lost condition is defined as a continuously active los condition for more than a period of lost seconds. the lost period is user programmable (see the lost time period command). no lost condition lost condition i2 reserved i3 activation timer: on an htu-r, the activation timer is activated when 2-level transmission begins. on an htu-c, the activation timer is activated when an activate command is issued and 2-level transmission begins. the timer is restarted when a far-end (htu-r) signal is detected. note: the activation timer defaults to 50 seconds for a 288kbps data rate system timer not expired timer expired i4 noise margin ok: indicates that the noise margin is better than a threshold of ? 5 db. noise margin ? 5db noise margin > ? 5 db i5 reserved i6 transmitter 4-level indicator: indicates that a 4-level signal is being transmitted. not transmitting 4-level transmitting 4-level i7 normal operation flag: this bit is set when the bit-pump successfully completes startup. this bit is cleared when the startup is first activated, when the deactivate command is issued, and when initialized. not normal operation normal operation opcode numeric value c constant (defined in file api.h) 0x86 _lec_coeff options option description data field c constant (api.h) coefficient index unsigned integer x, 0 x 59, indicating the index of the linear ec coefficient to be read. x
bt8960 appendix a command set reference software user ? s guide a.2 status request commands 100251b conexant a-21 preliminary information/conexant proprietary and confidential a.2.7.1 bit-pump response 1-byte signed integer x, containing the 8 msbs of the requested linear ec coefficient value. a.2.8 read non-linear echo canceler coefficient reads a specified non-linear echo canceler coefficient. a.2.8.1 bit-pump response signed integer x, containing the 8 msbs of the requested non-linear ec coefficient value. a.2.9 read eq coefficient reads a specified dagc, ffe, or ep coefficient. opcode numeric value c constant (defined in file api.h) 0x87 _nlec_coeff options option description data field c constant (api.h) coefficient index unsigned integer x, 0 x 63, indicating the index of the non-linear ec coefficient to be read. x opcode numeric value c constant (defined in file api.h) 0x88 _eq_coeff
appendix a command set reference bt8960 a.2 status request commands software user ? s guide a-22 conexant 100251b preliminary information/conexant proprietary and confidential a.2.9.1 bit-pump response signed integer containing the 8 msbs of the requested eq coefficient value. a.2.10 read dfe coefficient reads a specified dfe coefficient. options option description data field c constant (api.h) ffe coefficients request ffe coefficients 0 ? 70 ? 7 ffe data taps request ffe data taps 0 ? 78 ? 15 ep coefficients request ep coefficients 0 ? 416 ? 20 ep data taps request ep data taps 0 ? 421 ? 25 dagc gain request dagc gain value ? lsb request dagc gain value ? msb 26 27 dagc output request dagc output 28 ffe output request ffe output 29 dagc input request dagc input 30 ffe output, delayed 1 symbol request ffe output, delayed 1 symbol 31 dagc error signal request dagc error signal 32 equalizer error signal request equalizer error signal 33 slicer error signal request slicer error signal 34 reserved 35 ? 47 opcode numeric value c constant (defined in file api.h) 0x89 _dfe_coeff options option description data field c constant (api.h) coefficient index unsigned integer x, 0 x 57, indicating the index of the dfe coefficient to be read. x
bt8960 appendix a command set reference software user ? s guide a.2 status request commands 100251b conexant a-23 preliminary information/conexant proprietary and confidential a.2.10.1 bit-pump response signed integer x, containing the 8 msbs of the requested dfe coefficient value. a.2.11 software/chip version requests software and chip version numbers. opcode numeric value c constant (defined in file api.h) 0x8a _version options option description data field c constant (api.h) major sw version chip version the 4 lsbs of the status byte (bit 0 ? bit 3) contain the bit-pump major software version, bit 0 being the lsb. the 4 msbs of the status byte (bit 4 ? bit 7) indicate the bit-pump chip version, bit 4 being the lsb 0x00 _hw_sw_versions major sw version 1-byte unsigned integer field returning the major software version. 0x01 _major_sw_version minor sw version 1-byte unsigned integer field returning the minor software version. 0x02 _minor_sw_version bit-pump type chip version the 3 lsbs of the status byte (bit 0 ? bit2) contain the bit-pump type (see table below). bit 3 is undefined. the 4 msbs of the status byte (bit 4 ? bit 7) indicate the bit-pump chip version, bit 4 being the lsb. 0x03 _hw_type_versions bit-pump types bits 2-0 bit-pump type 000 bt8952 001 bt8960 010 ? 111 undefined
appendix a command set reference bt8960 a.2 status request commands software user ? s guide a-24 conexant 100251b preliminary information/conexant proprietary and confidential a.2.12 bit-pump present requests a bit-pump presence status. a positive response means that the bit-pump is present in the system and connected to the microprocessor. the presence of a bit-pump is determined by performing a write/read operation to a single internal bit-pump ram location. it is possible for hardware faults to masquerade as the presence of a bit-pump at a location. the presence of a bit-pump does not guarantee that all microprocessor bit-pump hardware connections are ok. a.2.12.1 bit-pump response 0x00: bit-pump not present 0x01: bit-pump present a.2.13 self test executes a bit-pump self-test. the self-test does not cover all aspects of the chip operation, but verifies read/write operations. a.2.13.1 bit-pump response 0x00: bit-pump self-test pass 0x01: bit-pump self-test fail opcode numeric value c constant (defined in file api.h) 0x8b _bit_pump_present options option description data field c constant (api.h) none 0x00 opcode numeric value c constant (defined in file api.h) 0x8c _self_test options option description data field c constant (api.h) none 0x00
bt8960 appendix a command set reference software user ? s guide a.2 status request commands 100251b conexant a-25 preliminary information/conexant proprietary and confidential a.2.14 read bt8960 register reads an internal bt8960 register. register address is required. a.2.14.1 bit-pump response value stored in specified bt8960 internal register. a.2.15 bit-pump configuration requests a bit-pump configuration. this includes user programmable options and parameters. opcode numeric value c constant (defined in file api.h) 0x8d _register options option description data field c constant (api.h) bt8960 register address address of internal bt8960 register to be read. see bt8960 datasheet for register address map. x opcode numeric value c constant (defined in file api.h) 0x8e _configuration option option description data field c constant (api.h) read low application setup byte read low byte of application setup word. see table a-3 for structure of application setup word. 0x00 _user_setup_low_byte read high application setup byte read high byte of application setup word. see table a-4 for structure of application setup word. 0x01 _user_setup_high_byte read lost time period read lost time period. the format of this status byte is identical to the format in the lost time period command. 0x02 _lost read symbol rate read symbol rate. the format of this status byte is identical to the format in the symbol rate command. 0x03 _bit_rate
appendix a command set reference bt8960 a.2 status request commands software user ? s guide a-26 conexant 100251b preliminary information/conexant proprietary and confidential all fields of the application setup word are coded in exactly the same way as the data field byte in the corresponding control command. for example, the two data transfer format bits (bits 0,1 of the high application setup byte) are interpreted exactly the same as the data field byte in the data transfer format command. the 4 test mode bits (test mode 0 ? test mode 3) show the current test mode index (numbered from 0 to 14) with test mode 0 being the lsb. a zero value indicates that no test mode is currently in effect. a non-zero value indicates that the bit-pump currently operates in the specified test mode. see the test mode command. a.2.16 stage number gets the bit-pump software stage number. a.2.16.1 bit-pump response the bt8960 software internal stage number. this stage number changes when the bit-pump goes through a activation procedure. file suc.h contains c definitions mapping the stage numbers to stage names. this command is only used for test and debug purposes. table a-4. low application setup byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 reserved other side bt8960 receive descr. transmit scramb. start-up sequence source analog agc config 1 analog agc config 0 terminal type table a-5. high application setup byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 test mode 3 test mode 2 test mode 1 test mode 0 reserved reserved data transfer format 1 data transfer format 0 opcode numeric value c constant (defined in file api.h) 0x8f _stage_number options option description data field c constant (api.h) none 0x00
bt8960 appendix a command set reference software user ? s guide a.2 status request commands 100251b conexant a-27 preliminary information/conexant proprietary and confidential a.2.17 aagc value gets the current value of the 3 aagc control bits. a.2.17.1 bit-pump response the 3 lsbs of this status byte reflect the state of the aagc control bits. this command is useful for calculating the true signal attenuation by compensating for the actual aagc gain (see far-end signal attenuation command). a.2.18 read tx gain reads the transmitter calibration/gain registers. the transmitter gain registers are a 4-bit, 2 ? s complement value. the upper 4 bits of this field are ignored. a.2.18.1 bit-pump response the tx calibration register contains the nominal setting for the transmitter gain. the tx gain register contains the current transmitter gain setting. on software initialization, the tx gain register is programmed to the tx calibration register. opcode numeric value c constant (defined in file api.h) 0x90 _aagc_value options option description data field c constant (api.h) none 0x00 opcode numeric value c constant (defined in file api.h) 0x91 _read_tx options option description data field c constant (api.h) tx calibration transmitter calibration register 0x00 _calibration tx gain transmitter gain register 0x01 _gain
appendix a command set reference bt8960 a.2 status request commands software user ? s guide a-28 conexant 100251b preliminary information/conexant proprietary and confidential a.2.19 ber meter status request the ber meter status. reading the ber meter status commands while the ber meter is enabled does not effect the ber meter operation. note: this command is only supported by versions 2.0+. opcode numeric value c constant (defined in file api.h) 0x92 _ber_meter_status options option description data field c constant (defined in file api.h) ber status read the ber meter status, see the ber status below for bit definitions. 0x00 _ber_status # bit errors low byte reads the low byte of the number of bit-errors. 0x01 _ber_bit_errors_low # bit errors high byte reads the high byte of the number of bit-errors. 0x02 _ber_bit_errors_high # meter intervals low byte reads the low byte of the number of meter intervals elapsed. 0x03 _ber_meter_intervals_low # meter intervals high byte reads the high byte of the number of meter intervals elapsed. 0x04 _ber_meter_intervals_high ber status bits status bit indicates value = 0 value = 1 0 ber meter enabled not active active 1- ? 7 reserved
bt8960 appendix a command set reference software user ? s guide a.3 special messages 100251b conexant a-29 preliminary information/conexant proprietary and confidential a.3special messages a.3.1 acknowledge this message is sent by the 8032 to acknowledge a correctly received message, in a serial communication ui configuration. the acknowledge message is 4 bytes long (like all other messages), with the first 3 being 0xff, 0xff, 0xff. byte 4 (last transmitted) is the standard checksum byte, which equals 0x55.
appendix a command set reference bt8960 a.3 special messages software user ? s guide a-30 conexant 100251b preliminary information/conexant proprietary and confidential
100251b conexant b-1 preliminary information/conexant proprietary and confidential b appendix b calibrating noise margin table b.1introduction the noise margin table defined in module user.c is calibrated to w & g ils 200 etsi loop 2 with 1.5 mhz shaped noise with low crest factor. this document describes the steps needed to calibrate the noise margin table to a user ? s specific noise source. the noise margin table has a 0.5 db resolution. b.1.1 setup use a line simulator or true line and a noise generator. select a simple standard loop like isdn loop 2 and perform startup. connect a ber meter to the hdsl equipment. b.1.2 noise margin table calibration b.1.2.1 calculate scale factor. 1. read meter timer high byte address 0x19, using the api command : _btstatus (loop_no, _register, 0x19, &scale); 2. calculate scale factor. scale_factor = ( (2^7) / scale); b.1.2.2 find 0 db noise margin reference point. 1. change the noise source until ber reading is 1.0e ? 7 (for 1 loop) or 5.0e ? 8 (for 2 loops). this point is the 0 db noise margin reference point
appendix b calibrating noise margin table bt8960 b.1 introduction software user ? s guide b-2 conexant 100251b preliminary information/conexant proprietary and confidential b.1.2.3 calculate reference point value. 1. read nlm meter low byte address 0x50, using the api command: _btstatus (loop_no, _register, 0x50, &low_byte); 2. read nlm meter high byte address 0x51, using the api command: _btstatus (loop_no, _register, 0x51, &high_byte); 3. combine the two nlm bytes (low_byte and high_byte) to an integer: nlm_value = 256 * high_byte + low_byte; 4. calculate the normalized value of noise level meter: nlm_value = nlm_value * (2^scale factor); 5. repeat steps 1 to 4 ten times. calculate the average nlm_value over the ten readings. b.1.2.4 set 0db reference point. 1. write the averaged value of noise level meter to cell 32 in the _noise_margin[] array, module user.c. b.1.2.5 calculate +0.5db margin. 1. decrement the noise source by 0.5 db. 2. repeat the calculate reference point value step b.1.2.3 (1 to 5). 3. write the calculated value to next higher cell. b.1.2.6 calculate positive margin. 1. repeat step b.1.2.5 (1 to 3) until the upper half of the table if full. the significant part of the table is 0 db to 15 db noise margin. higher margins can not be measured reliably. b.1.2.7 set noise source to 0db. 1. set the noise source to the 0 db noise margin reference point. b.1.2.8 calculate ? 0.5 db margin. 1. increment the noise source by 0.5 db. 2. repeat the calculate reference point value step b.1.2.3 (1 to 5). 3. write the calculated value to next lower cell. b.1.2.9 calculate negative margin. 1. repeat step b.1.2.8 (1 to 3) until the lower half of the table is full.
100251b conexant c-1 preliminary information/conexant proprietary and confidential c appendix c erle diagnostic code c.1introduction the erle program is a diagnostic tool to verify the integrity of the hardware ? s analog front-end and echo canceler. the erle program is useful when modifying the hybrid for different data rates. c.2what is erle? erle = echo return loss enhancement. four results are given from the erle program. 1. background noise test 2. erle 3. analog erle 4. aagc check the background test measures the slm while the transmitter is turned off. this effectively gives the amount of noise present at the input of the a/d. the erle result determines the amount of echo canceled. the echo is canceled initially by the external hybrid and then by the linear echo canceler in the bit-pump. the erle measurement is determined by the following formula. erle = 20 * log ( slm / felm ) slm = signal level meter felm = far end level meter the analog erle determines how much echo is canceled by the hybrid. this is done by bypassing the hybrid and measuring the input signal level meter. the analog erle measurement is determined by the following formula. erle = 20 * log ( slm2 / slm ) slm2 = signal level meter with hybrid input bypassed slm = signal level meter from erle result the aagc check makes sure the gain settings are monatomic. the aagc is the bit-pump ? s internal analog automatic gain control.
appendix c erle diagnostic code bt8960 c.3 erle files software user ? s guide c-2 conexant 100251b preliminary information/conexant proprietary and confidential c.3erle files the erle.c and erle.h files found in the bit-pump directory contains the erle functions. prior to calling these functions, the bit-pump must be configured using the appropriate api commands. c.3.1 _erle() the _erle() routine measures the background noise, erle, and analog erle. parameters: no - which bit-pump, _bit_pump0 - _bit_pump6 mode - mode of operation the mode bits are defined as follows: c.3.2 _measureaagc() the _measureaagc() routine verifies the gain settings are monatomic. parameters:no- which bit-pump, _bit_pump0 - _bit_pump6 routine description _erle() contains the erle diagnostic code. _erle() is used to measure the background noise, erle, and analog erle. _measureaagc() this function cycles through the aagc settings and measures the slm to make sure the gain settings are monatomic. bit description 0 adapt non-linear echo canceler. a ? 0 ? does not adapt the nlec. a ? 1 ? adapts the nlec. 1 reserved 2,3,4 select again setting. these 3 bits correspond to the 3 gain control bits of the adc control register (0x21). 000 = 0db 001 = 3 db 010 = 6 db 011 = 9 db 100 = 12 db 101 = 15 db 5,6,7 reserved
bt8960 appendix c erle diagnostic code software user ? s guide c.4 invoking the tests 100251b conexant c-3 preliminary information/conexant proprietary and confidential c.4invoking the tests c.4.1 background test to perform the background noise test, call _erle() when the transmitter is off. in this mode, the program adapts the lec (linear echo canceler). if the nlec (non linear echo canceler) mode is on, then the nlec is also adapted. after adapting the coefficients, the slm and felm are read and erle is calculated. the erle number is not important here, what is important are the slm and felm register values. c.4.2 erle and analog erle test to perform the erle and analog erle test, call _erle() when the transmitter is on. in this mode, the program adapts the lec (linear echo canceler). if the nlec (non linear echo canceler) mode is on, then the nlec is also adapted. after adapting the coefficients, the slm and felm are read and erle is calculated. after that, the hybrid bypass bit is set and analog erle is calculated. c.4.3 aagc check to perform the aagc check test, call the _measureaagc() when the transmitter is on. c.5compiling the erle code the erle code requires the compiler flag erle to be specified in the compiler flag define list. c.5.1 tdebug compiler flag the tdebug compiler is typically specified when generating the erle code. the tdebug provides a ? printf() ? environment to display the results. in the tdebug environment, an rs232 cable must be connected to a terminal emulator. note: the ser_com compiler flag can not be specified at the same time as the tdebug flag. however, it is possible to compile without the tdebug flag. if this is the case, then the user would be responsible for extracting the results.
appendix c erle diagnostic code bt8960 c.5 compiling the erle code software user ? s guide c-4 conexant 100251b preliminary information/conexant proprietary and confidential
100251b conexant d-1 preliminary information/conexant proprietary and confidential d appendix d release notes appendix d contains the previous release notes for the bt8960 software. these notes have also been incorporated into their respective sections within this user ? s guide. note: bt8960 bit-pump version 2.0, release notes ? november 13, 1996 d.1memory requirements the ram and rom requirements for four common build options with their associated compiler flags are given in table d-1 . d.1.0.1 bt8960cr w/o ber_meter c51, add_delay, pdata_mode, ser_com, htuc, htur, single_loop, chan_unit d.1.0.2 bt8960cr w/ ber_meter c51, add_delay, pdata_mode, ser_com, htuc, htur, single_loop, ber_meter, chan_unit d.1.0.3 bt8960c w/ ber_meter c51, add_delay, pdata_mode, ser_com, htuc, single_loop, ber_meter, chan_unit table d-1. ram and rom requirements build option ram rom bt8960cr w/o ber_meter 111 24.0 k bt8960cr w/ ber_meter 117 24.4 k bt8960c w/ ber_meter 117 20.0 k bt8960r w/ ber_meter 117 20.6 k note(s): the ram requirements do not include the stack size, an additional 24 bytes is required for the run-time stack.
appendix d release notes bt8960 d.1 memory requirements software user ? s guide d-2 conexant 100251b preliminary information/conexant proprietary and confidential d.1.0.4 bt8960r w/ ber_meter c51, add_delay, pdata_mode, ser_com, htur, single_loop, ber_meter, chan_unit d.1.1 bug fixes the following bugs were fixed in version 2.0. d.1.1.1 htu-c phase #0 = 0 vs aagccheck() bug when the aagccheck() incremented the gain setting, the linear ec was not re-adapted so the first phase quality (phase #0) always reported 0. to solve this, in the start_open_eye stage, always set the next stage to phase_adapt_ec1 instead of open_eye1; this will force the echo canceler to be re-adapted. fixing this bug improves startup reliability and performance. d.1.1.2 external and internal analog loopback the external and internal analog loopback function did not work properly in version 1.x. please see the analog loopbacks section below for details. d.1.2 support new bt8960 rev c version 2.0 supports the new bt8960 rev c silicon. the bt8960 rev c is identified by the package marking proto3 or es2, and the chip revision number 1 in the global modes register (addr. 0x00) and jtag id register. version 2.0 is backwards compatible with the existing bt8960 rev a & b parts. however, the existing version 1.x bt8960 bit-pump software is not forward compatible with the new rev c parts. d.1.2.1 _readaccessdatabyte() function when reading the indirect ram (i.e. linear echo canceler, equalizer register, etc.) of the bt8960 rev c silicon, there can not be any other write operations to the bt8960 after the indirect ram read address register (i.e. addr: 0x70, 0x72, etc.) is selected and before the access data byte registers (addr: 0x7c-0x7f) are read. in the bt8960 code, the only time this condition is violated is if an interrupt occurs in between selecting the read address and reading the access data bytes. the _readaccessdatabyte() function disables the interrupts whenever reading the indirect ram and re-enables the interrupts on exit. the four access data byte registers are stored in the global_access_data_byte[] array. the calling function or routine then just accesses this global array without interfering with the bit-pump registers. d.1.2.2 analog loopbacks the bt8960 rev c silicon fixed the isolated analog loopback. please see the analog loopbacks section below for details.
bt8960 appendix d release notes software user ? s guide d.1 memory requirements 100251b conexant d-3 preliminary information/conexant proprietary and confidential d.1.3 improved performance the startup reliability and performance for ansi loops #1 & #2 and maximum reach were significantly improved. d.1.3.1 phase quality selection in bit-pump version 1.x, a bt8960 system would occasionally select the incorrect optimal phase on some of the more difficult loops. during this bad startup, the system would successfully pass data but the noise margin would be noticeably worse than a good startup. in addition, the bt8960 could not startup on ansi loops #1 and #2. version 2.0 modified the optimal phase selection to provide a more robust algorithm for the bt8960 systems. this provides more reliable startups, the ability to startup on ansi loops #1 & #2, and gains more maximum reach. note: this improvement applies to both rev b and rev c silicon. d.1.4 new / modified features the following features were added or fixed in version 2.0. d.1.4.1 implemented internal ber meter implemented the bt8960 internal ber meter. please see the internal ber meter operation section below for details. d.1.4.2 read_meter_reg() macro during the ber meter operation, the bit-pump interrupt handler reads the ber meter register every meter interval. to insure that the interrupt doesn ? t occur in between reading the low byte and high byte of another meter register, the read_meter_reg() macro disables the bit-pump interrupt when accessing any of the meter registers. d.1.4.3 analog loopbacks the bt8960 supports 3 types of analog loopbacks: external, internal, and isolated. 1. external ? transmitter on, receiver uses both the receive (rxp, rxn) and hybrid (rxbp, rxbn) inputs. 2. internal ? transmitter on, receiver only uses the hybrid inputs (rxbp, rxbn). 3. isolated ? transmitter silent, internally loopbacked. table d-2 shows the relationship between the chip rev, software version, and analog loopbacks supported. table d-2. version relationships version external internal isolated v 1.x none none none v 2.0 rev b and c rev c only rev c only
appendix d release notes bt8960 d.1 memory requirements software user ? s guide d-4 conexant 100251b preliminary information/conexant proprietary and confidential d.1.5 new api commands the following api commands were added in version 2.0. d.1.5.1 tip/ring reversal this command reverses the tip/ring polarity on the received signal. however, the bt8960 does not reverse the tip/ring polarity on the transmitted signal. in addition, the bt8960 does not provide the ability to detect when tip/ring reversal is necessary. this command is useful in applications where a framer has the ability to detect tip/ring reversal but can not correct the tip/ring reversal. since this command only reverses the received signal, it is necessary to call this command on both the central and remote terminals when tip/ring reversal is detected. d.1.5.2 ber meter start this command activates the ber meter. the bit-pump is set to transmit an internal 4-level scrambled ones pattern. the enabled bit is set and the bit_errors & meter_intervals variables are reset to 0. this command should only be called during the bit-pump ? s normal operation. opcode numeric value c constant (defined in file api.h) 0x14 _reverse_tip_ring options option description data field c constant (defined in file api.h) tip/ring normal sets the tip/ring polarity on the received signal to normal (not-reversed). 0x00 tip/ring reverse reverses the tip/ring polarity on the received signal. 0x01 opcode numeric value c constant (defined in file api.h) 0x15 _ber_meter_start options option description data field c constant (defined in file api.h) none 0x00
bt8960 appendix d release notes software user ? s guide d.1 memory requirements 100251b conexant d-5 preliminary information/conexant proprietary and confidential d.1.5.3 ber meter stop this command deactivates the ber meter. the bit-pump is set to transmit external 4-level data, the transmit scrambler is set based on the current _transmit_scr api setting. the enabled bit is turned off. the bit_errors & meter_intervals variables are unmodified so they can be still read. d.1.5.4 ber meter status request the ber meter status. reading the ber meter status commands while the ber meter is enabled does not effect the ber meter operation. opcode numeric value c constant (defined in file api.h) 0x16 _ber_meter_stop options option description data field c constant (defined in file api.h) none 0x00 opcode numeric value c constant (defined in file api.h) 0x92 _ber_meter_status options option description data field c constant (defined in file api.h) ber status read the ber meter status, see the ber status below for bit definitions. 0x00 _ber_status # bit errors low byte reads the low byte of the number of bit-errors. 0x01 _ber_bit_errors_low # bit errors high byte reads the high byte of the number of bit-errors. 0x02 _ber_bit_errors_high # meter intervals low byte reads the low byte of the number of meter intervals elapsed. 0x03 _ber_meter_intervals_low # meter intervals high byte reads the high byte of the number of meter intervals elapsed. 0x04 _ber_meter_intervals_high
appendix d release notes bt8960 d.1 memory requirements software user ? s guide d-6 conexant 100251b preliminary information/conexant proprietary and confidential d.1.6 internal ber meter operation this section describes how to use the bt8960 ? s internal ber meter. the ber meter can be used to verify the integrity of the line. the ber meter can be used as a diagnostic tool during production/field testing or hardware/software development. the ber meter uses its internal scrambled ones generator & de-scrambler to detect bit-errors. for the ber meter to function properly, both the htu-c and htu-r must issue the _ber_meter_start api command. since the ber meter uses its own internal scrambled ones generator, the ber meter can be not used when transporting real payload data. the ber meter is only operational after the bit-pump has successfully completed startup. d.1.6.1 ber_meter compiler flag the ber_meter flag compiles in the ber meter code. the ber meter code adds ~400 bytes of rom and 1 byte of ram plus an additional 5 bytes of ram for each bit-pump. note: the ber_meter flag can not be declared when the int_bug compiler flag is specified. d.1.6.2 ber_meter api commands the ber meter api commands are discussed in section 5. d.1.6.3 calculating avg ber and elapsed time the following formulas are used to calculate the avg ber and elapsed time. ber status bits status bit indicates value = 0 value = 1 0 ber meter enabled not active active 1 ? 7 reserved avgber ofbiterror s ofmeterint ervals meterinter vallength = # #* *2 elapsedtim e ofmeterint ervals meterinter vallength datarate = #* *2
bt8960 appendix d release notes software user ? s guide d.1 memory requirements 100251b conexant d-7 preliminary information/conexant proprietary and confidential variable how derived # of bit-errors read the # of bit-errors low & high byte api commands and build a 16-bit unsigned integer. # of meter intervals read the # of meter intervals low & high byte api commands and build a 16-bit unsigned integer. meter interval length read the bt8960 meter interval register (address 0x18, 0x19) and build a 16-bit unsigned integer. during normal operation, these registers should always read 0x8000 (32768). data rate data rate of the system, i.e. 288000 or 416000. 2 the ? * 2 ? is necessary since there are 2 bits per symbol and the meter interval length is based on the number of symbols. note(s): 16-bit value = (high byte << 8) + (low byte) figure d-1. example /* * assuming 288kbps data rate, normal operation, and ber meter active * also assumes using compiler/linker that supports floating point. */ void get_ber_meter_status (unsigned char no) { unsigned char temp, temp1; unsigned int errors, intervals; float avg_ber, elapsed_time; _btstatus(no, _ber_meter_status, _ber_bit_errors_low, &temp); _btstatus(no, _ber_meter_status, _ber_bit_errors_high, &temp1); errors = (unsigned)byte2word(temp1, temp); _btstatus(no, _ber_meter_status, _ber_meter_intervals_low, &temp); _btstatus(no, _ber_meter_status, _ber_meter_intervals_high, &temp1) intervals = (unsigned)byte2word(temp1, temp); avg_ber = (errors) / (intervals * 0x8000 * 2) /* equations don?t show necessary type casting */ elapsed_time = (intervals * 0x8000 * 2) / (288000) #if tdebug printf("# bit errors = %u\n", errors); printf("# meter intervals = %u\n", intervals); printf("avg ber = %.2e\n", avg_ber); printf("elapsed time = %.1f seconds\n", elapsed_time); #endif return; } 100251_008
appendix d release notes bt8960 d.1 memory requirements software user ? s guide d-8 conexant 100251b preliminary information/conexant proprietary and confidential d.1.7 ber meter bit-pump code implementation this section describes how the bt8960 ? s internal ber meter is implemented in the bit-pump software. the user does not need to be aware of the exact details since all access to the ber meter status is done through the api. d.1.7.1 ber_meter_struct structure the user should not directly access the ber meter structure. the ber meter structure is defined as follows: #ifdef ber_meter typedef union { unsigned char reg; struct { unsigned char enabled:1; unsigned char :7; } bits; } ber_meter_status; typedef struct { ber_meter_status status; unsigned int bit_errors; unsigned int meter_intervals; }ber_meter_struct; extern ber_meter_struct idata ber_meter[_no_of_loops]; #endif the ber_meter array is stored in idata since it takes up 5 bytes of memory per bit-pump. be_meter_status: struct the ber_meter_status structure contains 1 field, enabled . the enabled flag is used to determine when the ber meter is currently active. the enabled bit is deactivated whenever the part is reset, startup is activated or deactivated, or the _ber_meter_stop api command is called. bit_errors: int this variable keeps track of the number of bit errors. this is updated every meter interval when the ber meter is enabled. this variable is reset whenever the _ber_meter_start api command is called. meter_intervals: int this variable keeps track of the number of meter intervals elapsed. this is updated every meter interval when the ber meter is enabled. this variable is reset whenever the _ber_meter_start api command is called. d.1.7.2 interrupt handler the interrupt handler reads the bit error rate meter register (address 0x4c, 0x4d) and updates the number of bit-errors and number of meter intervals counter after every meter interval. this causes the interrupt handler to be slightly longer, ~55us per bit-pump on an 11.0592mhz intel 8032.
bt8960 appendix d release notes software user ? s guide d.2 bt8960 bit-pump version 1.1, release notes?september 2, 1996 100251b conexant d-9 preliminary information/conexant proprietary and confidential d.2bt8960 bit-pump version 1.1, release notes ? september 2, 1996 d.2.1 pll modes clk_freq bits were incorrect the pll frequency #defines for 2 & 8 channel in api.h (line 116) were incorrect. however, the 4 and 6 channel #defines were correct. this bug could potentially impact the performance on systems running below 220kbps or running above 483kbps since the wrong clk_freq range setting was selected. the pll modes register (addr: 0x22) should be as follows: d.2.2 added erle support the erle code is a diagnostic tool to verify the integrity of the hardware ? s analog front-end and echo canceler. the files erle.c and erle.h contain the erle code. these 2 files are located in the bit-pump sub-directory. the script.bld file was modified to include the erle target. please see the bt8960 single-chip 2b1q transceiver bit-pump software user ? s guide version 1.1 (ug8960-1a) for complete details of the erle code. d.2.3 bt8960evm single board support brooktree now offers a production bt8960evm system. these systems have integrated the bt8960 chip, microprocessor, eprom, etc. onto a single pcb. the bt8960evm system now has separate code and data space unlike previous evm versions. the following changes were made to the bit-pump code to support the new systems: d.2.3.1 user.c - different bit-pump address mapping the bit-pump address map is located at 0x0000, the _bit_pump0_add #define was changed to reflect the new hardware. clk_freq[1,0] number of channels (n) resulting data rate nominal crystal center freq 00 4 288 kbps 9.216 mhz 01 6 416 kbps 13.312 mhz 10 2 160 kbps 5.120 mhz 11 reserved - - note(s): the ? reserved ? setting behaves identically to the 6 channel setting and not as an 8 channel setting as initially presumed. brooktree reserves the right to change the definition of the ? reserved ? setting.
appendix d release notes bt8960 d.2 bt8960 bit-pump version 1.1, release notes ? september 2, 1996 software user ? s guide d-10 conexant 100251b preliminary information/conexant proprietary and confidential d.2.3.2 script.bld - xdata mapping the lflags xdata() option was changed to 0x0000 to reflect the new hardware. in addition, the cflags is compiled with the single_loop bit-pump compiler option since the new hardware only supports one bit-pump. d.2.3.3 application code the high-level application code was modified to take advantage of the features of the new system. please see the bt8960 single-chip 2b1q transceiver evm software user ? s guide version 1.1 (ug8960-3a) and evm hardware user ? s guide (ug8960-4a) for complete details on the new bt8960evms.=
100251b conexant e-1 preliminary information/conexant proprietary and confidential e appendix e version 1.1 release notes bt8960 bit-pump version 1.1, release notes, september 2, 1996 e.1pll modes clk_freq bits were incorrect the pll frequency #defines for 2 & 8 channel in api.h (line 116) were incorrect. however, the 4 and 6 channel #defines were correct. this bug could potentially impact the performance on systems running below 220kbps or running above 483kbps since the wrong clk_freq range setting was selected. the pll modes register (addr: 0x22) should be as follows: clk_freq[1,0] number of channels (n) resulting data rate nominal crystal center freq 00 4 288 kbps 9.216 mhz 01 6 416 kbps 13.312 mhz 10 2 160 kbps 5.120 mhz 11 reserved - - note(s): the ? reserved ? setting behaves identically to the 6 channel setting and not as an 8 channel setting as initially presumed. brooktree reserves the right to change the definition of the ? reserved ? setting.
appendix e version 1.1 release notes bt8960 e.2 added erle support software user ? s guide e-2 conexant 100251b preliminary information/conexant proprietary and confidential e.2added erle support the erle code is a diagnostic tool to verify the integrity of the hardware ? s analog front-end and echo canceler. the files erle.c and erle.h contain the erle code. these 2 files are located in the bit-pump sub-directory. the script.bld file was modified to include the erle target. please see the bt8960 single-chip 2b1q transceiver bit-pump software user ? s guide version 1.1 (ug8960-1a) for complete details of the erle code. e.3bt8960evm single board support brooktree now offers a production bt8960evm system. these systems have integrated the bt8960 chip, microprocessor, eprom, etc. onto a single pcb. the bt8960evm system now has separate code and data space unlike previous evm versions. the following changes were made to the bit-pump code to support the new systems: e.3.1 user.c - different bit-pump address mapping the bit-pump address map is located at 0x0000, the _bit_pump0_add #define was changed to reflect the new hardware. e.3.2 script.bld - xdata mapping the lflags xdata() option was changed to 0x0000 to reflect the new hardware. in addition, the cflags is compiled with the single_loop bit-pump compiler option since the new hardware only supports one bit-pump. e.3.3 application code the high-level application code was modified to take advantage of the features of the new system. please see the bt8960 single-chip 2b1q transceiver evm software user ? s guide version 1.1 (ug8960-3a) and evm hardware user ? s guide (ug8960-4a) for complete details on the new bt8960evms.
further information literature@conexant.com (800) 854-8099 (north america) (949) 483-6996 (international) printed in usa world headquarters conexant systems, inc. 4311 jamboree road newport beach, ca 92660-3007 phone: (949) 483-4600 fax 1: (949) 483-4078 fax 2: (949) 483-4391 americas u.s. northwest/ pacific northwest ? santa clara phone: (408) 249-9696 fax: (408) 249-7113 u.s. southwest ? los angeles phone: (805) 376-0559 fax: (805) 376-8180 u.s. southwest ? orange county phone: (949) 483-9119 fax: (949) 483-9090 u.s. southwest ? san diego phone: (858) 713-3374 fax: (858) 713-4001 u.s. north central ? illinois phone: (630) 773-3454 fax: (630) 773-3907 u.s. south central ? texas phone: (972) 733-0723 fax: (972) 407-0639 u.s. northeast ? massachusetts phone: (978) 367-3200 fax: (978) 256-6868 u.s. southeast ? north carolina phone: (919) 858-9110 fax: (919) 858-8669 u.s. southeast ? florida/ south america phone: (727) 799-8406 fax: (727) 799-8306 u.s. mid-atlantic ? pennsylvania phone: (215) 244-6784 fax: (215) 244-9292 canada ? ontario phone: (613) 271-2358 fax: (613) 271-2359 europe europe central ? germany phone: +49 89 829-1320 fax: +49 89 834-2734 europe north ? england phone: +44 1344 486444 fax: +44 1344 486555 europe ? israel/greece phone: +972 9 9524000 fax: +972 9 9573732 europe south ? france phone: +33 1 41 44 36 51 fax: +33 1 41 44 36 90 europe mediterranean ? italy phone: +39 02 93179911 fax: +39 02 93179913 europe ? sweden phone: +46 (0) 8 5091 4319 fax: +46 (0) 8 590 041 10 europe ? finland phone: +358 (0) 9 85 666 435 fax: +358 (0) 9 85 666 220 asia ? pacific taiwan phone: (886-2) 2-720-0282 fax: (886-2) 2-757-6760 australia phone: (61-2) 9869 4088 fax: (61-2) 9869 4077 china ? central phone: 86-21-6361-2515 fax: 86-21-6361-2516 china ? south phone: (852) 2 827-0181 fax: (852) 2 827-6488 china ? south (satellite) phone: (86) 755-5182495 china ? north phone: (86-10) 8529-9777 fax: (86-10) 8529-9778 india phone: (91-11) 692-4789 fax: (91-11) 692-4712 korea phone: (82-2) 565-2880 fax: (82-2) 565-1440 korea (satellite) phone: (82-53) 745-2880 fax: (82-53) 745-1440 singapore phone: (65) 737 7355 fax: (65) 737 9077 japan phone: (81-3) 5371 1520 fax: (81-3) 5371 1501 www.conexant.com 0 . 0 sa l es offi ces

▲Up To Search▲

Price & Availability of 28960-SWG-001-A

	To Download 28960-SWG-001-A Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .